Техническое: доступность 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. 8th May 2018, 23:01 // Читатель laskin написал:

    На то придуман hsts preload. Ну и про ipv6 РКН ещё не в курсе.

  • 2. 8th May 2018, 23:32 // Читатель Beldmit написал:

    HSTS аналогичного эффекта не даст?

  • 3. 8th May 2018, 23:44 // Александр Венедюхин ответил:

    HSTS, да, как раз даёт нужный эффект. Наличие ещё и HPKP – оно только не позволяет вручную принять кривой подменный сертификат (а также выявит валидный сертификат с кривым ключом, но это, конечно, скорее теоретический случай).

  • 4. 8th May 2018, 23:55 // Александр Венедюхин ответил:

    > На то придуман hsts preload.

    dxdt.ru не проходит – у меня есть несколько поддоменов с сайтами, доступными по HTTP. Например, http://svg.dxdt.ru/.

  • 5. 10th May 2018, 21:26 // Читатель fdsc написал:

    Интересно, что там с Гуглом. С чего вдруг ему ненравится HPKP?
    Очень интересно было бы послушать более подробно. Ну, либо ссылочку какую-нибудь киньте хотя бы, если лень писать пост.

  • 6. 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. 11th May 2018, 09:20 // Читатель fdsc написал:

    Спасибо. Не понимаю, как, по мнению гугла, Certificate Transparency заменяет HPKP.

    > не желает давать в руки пользователям распределённый, независимый от некоторого центра инструмент проверки подлинности сайтов

    А зачем Гуглу это нужно реально?
    Скрытое давление АНБ или какие-то свои проблемы?

  • 8. 16th May 2018, 18:34 // Александр Венедюхин ответил:

    > как, по мнению гугла, Certificate Transparency заменяет HPKP.

    Видимо, заменяет потому, что там можно (в теории) проверить соответствие сертификатов именам. Но, конечно, это совсем другой вариант.

    > А зачем Гуглу это нужно реально?

    Думаю, для того, чтобы сохранять собственное “центральное положение”.

  • 9. 20th May 2018, 10:41 // Читатель fdsc написал:

    > Думаю, для того, чтобы сохранять собственное “центральное положение”.

    А каким образом ему мешает в этом HPKP?
    Ведь Google Chrome, кажется, даже не имеет своего списка удостоверяющих центров. Вроде бы, он их копирует у Mozilla, если я верно понимаю.
    И сам он центром сертификации не является.