Техническое: доступность dxdt.ru

8. May 2018, 22:19 blog, Безопасность, Интернет

Сейчас сайт снова должен быть доступен из сетей российских провайдеров в штатном режиме. Так как некоторое время назад многочисленные сети (миллионы 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/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 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, если я верно понимаю.
    И сам он центром сертификации не является.

Написать комментарий

Ваш комментарий:

Введите ключевое слово "UUQFG" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.