Техническое: доступность dxdt.ru
Сейчас сайт снова должен быть доступен из сетей российских провайдеров в штатном режиме. Так как некоторое время назад многочисленные сети (миллионы IP-адресов) попали под блокировку, в том числе, и подсеть с адресами dxdt.ru, пришлось добавить IP-адресов сайту. Это делается при помощи внесения дополнительных A-записей в DNS. Я добавил ещё три адреса, сделав на соответствующих узлах TCP-туннели к основному серверу (сейчас уже вернул единственный адрес, так как блокировки пошли на спад).
Почему это работало. В случае наличия нескольких адресов, браузер, обнаружив недоступность какого-то из них (из-за блокировок у провайдера), должен попробовать установить соединение с другим адресом. В принципе, всё примерно так и выходило, но только не в случае HTTP: потому что для HTTP некоторые провайдеры показывали “заглушку”, сообщающую о том, что сайт заблокирован. Соответственно, браузер полагал, что эта заглушка и есть сайт, и не делал попыток обратиться по другим адресам. Тут нужно учитывать следующий момент: первый GET-запрос, для извлечения основного тела документа, браузер всегда делает только по одному из адресов; это обусловлено тем, что отправлять два одинаковых запроса на разные IP-адреса в ситуации нормальной работы Сети особого смысла нет, это лишь создаст дополнительный трафик и нагрузку. Уже после того, как получен основной код страницы, браузер обращается ко всем доступным IP-адресам веб-узла параллельно, за сопутствующими ресурсами, а именно – за картинками, таблицами стилей и так далее. Но когда провайдер перехватывает запрос и подменяет узел dxdt.ru на свой собственный, браузер получает код этой провайдерской страницы. В итоге, если пользователю с HTTP не повезло, и его браузер обратился именно к заблокированному IP-адресу из имеющихся, то и на сайт браузер уже не попадёт, до повторной попытки загрузки.
А вот с HTTPS ситуация гораздо лучше: пока что не все провайдеры пытаются подменять TLS-узлы, поэтому соответствующие TCP-соединения просто разрываются, а браузер сразу видит, что этот адрес нерабочий и прозрачно переходит к следующему. Вмешательство же провайдера в TLS-соединение при помощи подмены узла – будет приводить к появлению предупреждения браузера. Так как dxdt.ru использует HPKP, это предупреждение во многих браузерах нельзя “подавить”, кликнув что-нибудь вроде кнопки “Всё равно продолжить”. Таким образом, HPKP тоже очень хорошо помогает в подобных случаях. Кстати, Google собирается убрать поддержку HPKP из Chrome, под совершенно надуманным предлогом. Это, в принципе, понятно: корпорация, с некоторых пор, не желает давать в руки пользователям распределённый, независимый от некоторого центра инструмент проверки подлинности сайтов. Впрочем, это другая история.
Итак, сайт dxdt.ru должен быть опять доступен.
Адрес записки: https://dxdt.ru/2018/05/08/8511/
Похожие записки:
- Статья о квантовых вычислениях и постквантовой криптографии
- Записки за март 2024
- Централизованные мессенджеры и многообразие мест хранения сообщений
- Встроенное проксирование в Google Chrome (IP Protection)
- Задержки пакетов, СУБД, TCP и РЛС
- Reuters о сети разведывательных спутников SpaceX
- Токены доступа и популярная автоматизация
- Обновление "Избранных записок", 2022
- Обновление описания TLS, 2024
- Продолжение сегментации: Docker Hub
- "Умные колонки" и отключение микрофона кнопкой
Комментарии читателей блога: 9
1 <t> // 8th May 2018, 23:01 // Читатель laskin написал:
На то придуман hsts preload. Ну и про ipv6 РКН ещё не в курсе.
2 <t> // 8th May 2018, 23:32 // Читатель Beldmit написал:
HSTS аналогичного эффекта не даст?
3 <t> // 8th May 2018, 23:44 // Александр Венедюхин:
HSTS, да, как раз даёт нужный эффект. Наличие ещё и HPKP – оно только не позволяет вручную принять кривой подменный сертификат (а также выявит валидный сертификат с кривым ключом, но это, конечно, скорее теоретический случай).
4 <t> // 8th May 2018, 23:55 // Александр Венедюхин:
> На то придуман hsts preload.
dxdt.ru не проходит – у меня есть несколько поддоменов с сайтами, доступными по HTTP. Например, http://svg.dxdt.ru/.
5 <t> // 10th May 2018, 21:26 // Читатель fdsc написал:
Интересно, что там с Гуглом. С чего вдруг ему ненравится HPKP?
Очень интересно было бы послушать более подробно. Ну, либо ссылочку какую-нибудь киньте хотя бы, если лень писать пост.
6 <t> // 10th May 2018, 23:20 // Александр Венедюхин:
Предлоги весьма надуманные: типа, может быть использовано для принудительного “запирания” сайта, если злоумышленник получит доступ к серверу и подставит отпечатки своих ключей; или вот ещё причина – просто есть “риск сделать сайт недоступным” (прямо так и пишут в исходном предложении: “There is a risk of rendering a site unusable”). Кроме того, якобы технология противоречит идеологии Open Web Platform. В общем, довольно странно это всё выглядит. Тем более, что в качестве “замены” предлагается использовать HTTP-заголовки Certificate Transparency. Вот ссылка: https://groups.google.com/a/chromium.org/d/topic/blink-dev/he9tr7p3rZ8/discussion
7 <t> // 11th May 2018, 09:20 // Читатель fdsc написал:
Спасибо. Не понимаю, как, по мнению гугла, Certificate Transparency заменяет HPKP.
> не желает давать в руки пользователям распределённый, независимый от некоторого центра инструмент проверки подлинности сайтов
А зачем Гуглу это нужно реально?
Скрытое давление АНБ или какие-то свои проблемы?
8 <t> // 16th May 2018, 18:34 // Александр Венедюхин:
> как, по мнению гугла, Certificate Transparency заменяет HPKP.
Видимо, заменяет потому, что там можно (в теории) проверить соответствие сертификатов именам. Но, конечно, это совсем другой вариант.
> А зачем Гуглу это нужно реально?
Думаю, для того, чтобы сохранять собственное “центральное положение”.
9 <t> // 20th May 2018, 10:41 // Читатель fdsc написал:
> Думаю, для того, чтобы сохранять собственное “центральное положение”.
А каким образом ему мешает в этом HPKP?
Ведь Google Chrome, кажется, даже не имеет своего списка удостоверяющих центров. Вроде бы, он их копирует у Mozilla, если я верно понимаю.
И сам он центром сертификации не является.
Написать комментарий