Великий китайский файрвол теперь блокирует HTTPS-трафик с TLS 1.3 и ESNI

Великий китайский файрвол теперь блокирует HTTPS-трафик с TLS 1.3 и ESNI

Великий китайский файрвол теперь блокирует HTTPS-трафик с TLS 1.3 и ESNI

Власти Китая отныне полностью блокируют HTTPS-трафик, использующий TLS 1.3 с ESNI. Таким образом, «Великий китайский файрвол» — инструмент государственной цензуры — стал ещё функциональнее.

По данным организаций, отслеживающих китайские методы блокировки, новые возможности «Великого файрвола» действуют с конца июля. Об этом сообщили аналитики Мэрилендского университета, iYouPort и Great Firewall Report.

Судя по всему, власти Китая нацелились исключительно на HTTPS-трафик, передаваемый с помощью современных протоколов TLS 1.3 и расширения ESNI (Encrypted Server Name Indication).

При этом в стране доступен весь остальной HTTPS-трафик, действующий посредством старых версий протоколов — TLS 1.1 или 1.2, а также расширения SNI (Server Name Indication).

Такому подходу есть вполне логичное объяснение: в случае HTTPS-соединений, опирающихся на старые протоколы, китайские власти могут вычислить домен, к которому обращается тот или иной гражданин.

Сделать это просто, достаточно лишь посмотреть на поле SNI (в виде простого текста) на ранних стадиях соединения. Но с TLS 1.3 + ESNI такой трюк уже не пройдёт.

При этом TLS 1.3 сегодня активно внедряется в Сети, и HTTPS с TLS 1.3 + ESNI доставляет правительству Китая серьёзные проблемы. При таком раскладе властям сложнее фильтровать трафик и контролировать, к какому контенту могут получать доступ граждане КНР.

Решить проблему помогла блокировка всего HTTPS-трафика, где используется TLS 1.3 + ESNI.

Тем не менее, как сообщили исследователи iYouPort, существуют шесть разных методов обхода блокировок на стороне клиента (внутри приложений). Ещё четыре способа можно реализовать на стороне сервера.

Вышла утилита RKN Block Checker для диагностики блокировок

Разработчик Дмитрий Виноградов представил утилиту RKN Block Checker с открытым исходным кодом. Она помогает понять, почему конкретный сайт не открывается: это обычная сетевая проблема или блокировка на стороне провайдера / регуляторной инфраструктуры.

Проект написан на Python и опубликован под лицензией MIT. Утилита работает из командной строки и проверяет соединение по цепочке DNS → TCP → TLS → HTTP.

Идея простая: не просто выдать вердикт, что сайт недоступен, а показать, на каком именно уровне всё сломалось. Например, если системный DNS не даёт нормальный ответ, а Cloudflare DoH возвращает корректный адрес, это может указывать на DNS-подмену. Если TCP-соединение на 443-й порт сбрасывается, речь может идти о блокировке на уровне IP.

Если TCP проходит, но соединение рвётся на TLS-рукопожатии с SNI, это уже похоже на работу DPI / ТСПУ. А если сайт открывается, но вместо страницы приходит заглушка провайдера или код 451, утилита фиксирует и такой сценарий.

 

Автор отдельно подчёркивает, что смысл RKN Block Checker не в том, чтобы заменить браузер. Браузер и так сообщает, что сайт не открылся. Здесь задача другая — разложить проблему по слоям и дать пользователю более понятную картину, где именно произошёл сбой и на что это похоже.

Утилита сравнивает ответы системного DNS и DNS over HTTPS через Cloudflare, проверяет обычное TCP-подключение, запускает TLS-handshake с SNI целевого домена и затем делает HTTP-запрос. Вердикт выставляется по первому уровню, на котором возникла ошибка.

 

У проекта есть и ограничения. Пока поддерживается только IPv4. Списки целей жёстко заданы в коде и включают около 20 сайтов на категорию, поэтому инструмент не поймает все частные случаи. Кроме того, это разовая проверка без повторов и долгосрочного мониторинга, хотя JSON-вывод можно использовать в cron для регулярных запусков.

RSS: Новости на портале Anti-Malware.ru