ECH (Encrypted Client Hello): обход блокировки по SNI

Когда браузер открывает HTTPS-сайт, он отправляет серверу первый пакет TLS - ClientHello. В нём есть поле SNI (Server Name Indication) с именем домена, к которому вы подключаетесь. Это поле нужно, чтобы один IP-адрес мог обслуживать тысячи сайтов: сервер по SNI понимает, какой сертификат предъявить. Проблема в том, что в TLS 1.2 и даже в TLS 1.3 поле SNI передаётся открытым текстом - до того, как стороны договорятся о ключах шифрования.

Для ТСПУ (технических средств противодействия угрозам) это подарок. Оборудование DPI у российских операторов не дешифрует трафик - это дорого и невозможно при масштабе. Вместо этого оно просто читает открытый SNI в каждом ClientHello и сверяет с реестром. Совпало имя запрещённого домена - соединение рвётся ещё до установления шифрованного канала. Так блокируется огромная доля ресурсов: дёшево, массово, по одному текстовому полю.

ECH (Encrypted Client Hello, RFC 9460/проект TLS ECH) убирает эту последнюю незашифрованную утечку метаданных. После TLS 1.3, который уже спрятал сертификат сервера, SNI оставался единственным, что наблюдатель видел в открытую. ECH шифрует и его.

ECH делит ClientHello на две части - внешний (outer) и внутренний (inner):

• Внутренний ClientHello содержит настоящее имя сайта, к которому вы идёте. Он шифруется публичным ключом сервера и для стороннего наблюдателя нечитаем.
• Внешний ClientHello несёт «прикрытие» - публичное имя (public_name). У Cloudflare это cloudflare-ech.com. Именно его, и только его, видит ТСПУ.

Откуда клиент берёт публичный ключ для шифрования внутренней части? Из DNS - из записи типа HTTPS (RR type 65), в которой публикуется параметр ech=. Проверить, поддерживает ли домен ECH, можно командой:

dig +short HTTPS example.com
# в ответе ищите блок ech=...

Логическая цепочка такая: клиент через DNS узнаёт ECH-конфиг сайта, шифрует им настоящий SNI, в открытую отправляет лишь безобидный public_name, а сервер (или фронт вроде Cloudflare) расшифровывает внутреннюю часть и направляет трафик куда нужно. Наблюдатель видит миллионы соединений к одному и тому же общему public_name и не может отличить, кто идёт на запрещённый ресурс, а кто - на разрешённый. В этом и есть «смена правил игры»: блокировка по SNI перестаёт работать, потому что блокировать пришлось бы общий домен-прикрытие, за которым стоят тысячи легитимных сайтов.

Здесь важно быть честным, а не продавать иллюзию. ECH - не «серебряная пуля» против РКН. Ещё 7 ноября 2024 года Роскомнадзор официально объявил ограничение ECH, и ТСПУ начало блокировать ECH-соединения к Cloudflare. Механизм блокировки точечный и показывает, где у ECH слабое место:

• ТСПУ не расшифровывает внутренний SNI - оно по-прежнему этого не умеет.
• Вместо этого оно ловит соединение, в котором одновременно присутствуют расширение ECH в ClientHello и публичное имя cloudflare-ech.com в открытом SNI.
• Срабатывает только на диапазонах IP, принадлежащих Cloudflare. Такой ClientHello просто отбрасывается (drop).

То есть РКН не сломал ECH как протокол - он заблокировал конкретную массовую и предсказуемую реализацию: всем зонам Cloudflare выдаётся один и тот же публичный домен-прикрытие. Этот статичный, общеизвестный public_name и стал сигнатурой. Урок прямой: уязвимость ECH - не шифрование (оно работает), а узнаваемость внешней, незашифрованной обёртки.

Вариант 1. Через Cloudflare. Если ваш домен на Cloudflare, ECH включается тривиально: на бесплатных тарифах он активирован по умолчанию, на платных - переключателем Encrypted ClientHello в разделе Edge Certificates панели. Cloudflare сам публикует ECH-конфиг в DNS (запись HTTPS) и расшифровывает внутренний ClientHello на своём фронте. Минус для российского пользователя мы описали выше: это ровно тот сценарий с cloudflare-ech.com, который ТСПУ уже режет. Для аудитории вне РФ - отлично; против РКН в лоб - нет.

Вариант 2. ECH на собственном офшорном VPS. Здесь и кроется реальный смысл для обхода. Если вы поднимаете ECH-терминацию сами, вы сами задаёте public_name - и он не обязан быть узнаваемым. Что для этого нужно на 2026 год:

• веб-сервер или реверс-прокси с поддержкой ECH - сборки nginx или собственный прокси, слинкованные с ECH-вариантом OpenSSL/BoringSSL (поддержка всё ещё «свежая», читайте changelog своей версии);
• сгенерировать ECHConfig и публичный ключ, опубликовать параметр ech= в DNS-записи HTTPS вашего домена;
• выбрать неприметный, не привязанный к одному провайдеру public_name - чтобы внешняя обёртка не выдавала ни Cloudflare, ни «прокси вообще»;
• помнить, что ECH чувствителен к DNS: если сеть вырезает параметр ech= из HTTPS-записи (а ТСПУ это умеет через подмену DNS), клиент откатится на обычный SNI. Поэтому ECH практически всегда сочетают с DoH/DoT - шифрованным DNS, который не даёт оператору вмешаться в ответ.

Отдельно стоит знать про GREASE ECH: браузеры (Chrome, Firefox) умеют отправлять фиктивное ECH-расширение даже на серверы без поддержки ECH. Это делает ECH-трафик неотличимым от обычного и затрудняет блокировку «всего, что похоже на ECH» оптом - заблокировать пришлось бы и легитимные браузеры.

ECH прячет имя сайта, но не меняет физику маршрута. Терминировать ECH и расшифровывать внутренний SNI должен сервер, которому вы доверяете и который стоит вне зоны российской фильтрации. На VPS в российском дата-центре весь смысл теряется: трафик не покидает периметр ТСПУ, а провайдер подчиняется тем же предписаниям, что и операторы связи.

Наши офшорные VPS в Финляндии, Исландии и Румынии дают то, что нужно для собственной ECH-терминации: root-доступ сразу после оплаты (можно собрать nginx с ECH-OpenSSL и поднять свой DoH-резолвер), чистый выходной IP вне Cloudflare-диапазонов и юрисдикцию вне досягаемости российских предписаний о раскрытии. Финляндия даёт минимальную задержку до Москвы, Исландия - наилучшую приватность. Для постоянной нагрузки или нескольких пользователей подойдёт выделенный сервер с гарантированными ядрами.

Практический вывод 2026 года: ECH - правильный и важный сдвиг, он добивает последнюю открытую утечку метаданных в TLS, но против РКН он работает только тогда, когда вы контролируете public_name и DNS сами. Если же цель - просто стабильный обход ТСПУ без возни с экспериментальными сборками, более зрелым инструментом сегодня остаётся VLESS+Reality на своём VPS, который маскирует соединение под визит к настоящему крупному сайту и проходит активное зондирование. ECH и Reality не исключают друг друга - это разные слои одной стратегии: не давать наблюдателю ни одного дешёвого признака для блокировки.