dxdt.blog: занимательный интернет-журнал

Ракета.

К наступающему новому году – подборка ранее опубликованных записок:

• DNS-over-HTTPS в браузере Firefox, блокировки и будущее Сети
• “Спутниковые интернеты” и обнаружение наземных станций доступа
• TLS, зашифрованные протоколы и DPI
• Кто видит как кошка
• Скрытые сервисы и прокси

И ещё одна важная ссылка – в начале 2019 года в “Открытых системах” опубликована моя статья про будущее блокировок доступа к ресурсам глобальной Сети: “За час до закрытия Интернета”.

С наступающим Новым годом! Спасибо, что читаете!

Добавил к техническому описанию TLS совсем краткое приложение, рассказывающее про DNS-over-HTTPS и DNS-over-TLS как примеры использования TLS для защиты других протоколов. Так как это приложение, и оно небольшое, основную версию документа решил не менять.

Вообще, в этом году обновлений для описания TLS получилось не так много. В июле я внёс исправления и уточнения в основной текст, добавил описание ESNI и приложение, рассказывающее на элементарном уровне о некоторых математических аспектах криптографии на эллиптических кривых (на мой взгляд, это довольно полезное приложение). Посмотрим, как будет развиваться тема в следующем году.

Выпустил (некоторое время назад) очередное обновление технического описания протокола TLS.

Обновление не очень большое, тем не менее: во-первых, я перечитал весь текст и внёс мелкие правки, дополнения и исправления (в частности, исправил ряд опечаток, обнаруженных читателями); во-вторых, добавил краткое описание ESNI (технологии, позволяющей передавать имя сервера в защищённом виде); в третьих, опубликовал короткое приложение под названием “Конечные поля и эллиптические кривые в криптографии”.

Приложение, на мой взгляд, самое интересное в обновлении: это очень упрощённое и, надеюсь, доступное описание прикладной математической части, стоящей за реализациями “криптографии на эллиптических кривых”. Там нет известной картинки, иллюстрирующей метод секущих и касательных, а только алгебра (самая простая, она стоит за упомянутой картинкой), но это именно та алгебра, которая прямо используется в TLS на практике.

Добавил поддержку TLS 1.3 (это самая свежая версия протокола) на сервере, где работает dxdt.ru. Сейчас на сервере доступны только TLS 1.3 и TLS 1.2 (все более ранние – я отключил). Так как поддержка актуальной версии TLS требует подходящей версии Apache (собранного с веткой OpenSSL 1.1.1), то пришлось перейти с операционной системы CentOS 7 на Fedora 30, где все нужные сборки есть “из коробки” (вариант собрать “в сторонке” и OpenSSL, и Apache, и mod_ssl из исходников – как-то не очень, даже с учётом того, что мне это приходится проделывать в рамках других проектов). А в CentOS, к сожалению, непонятно когда появится TLS 1.3, данная ОС постепенно становится малопригодной для использования.

Тем не менее, вроде бы ничего особенно не сломалось, а сайт работает.

Некоторое время назад тестовый сервер TLS 1.3, который я реализовал и, в меру сил, поддерживаю по адресу tls13.1d.pw, продемонстрировал свою практическую полезность. А я забыл об этом написать на dxdt.ru – соответственно, пишу сейчас.

Тестовый сервер поддерживает сочетание HelloRetryRequest (HRR) и ESNI (зашифрованное поле SNI). То есть, сервер иногда отправляет клиенту запрос на пересогласование параметров и при этом обрабатывает ESNI. HRR+ESNI – весьма редкое сочетание, на обычном сервере скорее не встречается (но может быть имитировано в рамках активной атаки), это и позволило мне обнаружить в NSS (библиотека, используемая браузером Firefox) ошибку, которая до этого успешно прошла через релиз-тесты.

Ошибка состояла в следующем: использование ESNI должно скрывать имя сервера, но в NSS соединение с HRR+ESNI обрабатывалось некорректно, соответственно, во втором ClientHello, в ответ на запрос HRR, имя сервера передавалось в открытом виде (в обычном расширении SNI). В итоге – утекало имя сервера, а на tls13.1d.pw в некоторых случаях не удавалось отобразить сведения про ESNI для пользователей Firefox (причина в том, что во втором ClientHello, из которого только и имеет смысл брать сведения о соединении, ESNI просто не было). Об ошибке я сообщил в Mozilla, ошибка (Bug 1517714) исправлена в релизе NSS_3.43, вышедшем в марте. Сейчас исправленный релиз уже разошёлся по всем основным сборкам браузера Firefox.

Ракета, стартующая на далёкой планете.

Пара статей, которые вышли некоторое время назад.

В “Открытых системах” опубликована моя статья про фильтрацию и блокировки в Интернете. В основном, с точки зрения использования метаинформации для обеспечения избирательности фильтров, применительно к DNS и Вебу (здесь рассматривается HTTPS), но и про возможное развитие в разрезе маршрутизации трафика тоже немного порассуждал, в разделе “Перспективы и фантастика”.
Ссылка: “За час до закрытия Интернета“.

На ресурсе D-Russia.ru – моя статья о зависимостях веб-сайтов от “внешних” библиотек. Речь про различные jQuery и т.п., которые загружаются с централизованных сервисов, являющихся внешними относительно сайта-источника. Такие зависимости очень распространены, но про них забывают (и пользователи, и администраторы веб-сайтов).
Ссылка: “Централизованный Интернет“.

Традиционная новогодняя записка на dxdt.ru. В этот раз – подборка из нескольких избранных записок, опубликованных в 2018 году. Записок теперь стало немного, но, надеюсь, среди них попадаются интересные.

• Подмена DNS-трафика в сетях LTE
• Формула для групп из TLS
• Фрукты и эллиптические кривые
• Domain Fronting, AWS и блокировки с обходом
• “Ключи на клиенте” и протокол Диффи-Хеллмана

Спасибо, что читаете. С наступающим Новым Годом!

На 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 должен быть опять доступен.