Методика

TLS 1.3 + Encrypted Client Hello (ECH): почему это меняет всё в 2026

Команда vpn-rating.xyz · 31 мая 2026 г. · обновлено 31 мая 2026 г. · ⏱ 9 мин

§ в этой статье — 11 разделов

Зачем понадобился ECH
Архитектура ECH
Где ECH уже включён в 2026
Реакция ТСПУ — что происходит в РФ-2026
Что значит для VPN
Контрмеры со стороны ТСПУ — варианты 2027
Практика — как использовать ECH сейчас
Открытые проблемы
Прогноз 2027-2028
Пользовательский опыт после ECH
Связанные материалы

К маю 2026 Encrypted Client Hello (ECH) — самое значимое изменение в TLS-стеке за последние десять лет, и одновременно — главный архитектурный вызов для DPI-систем по всему миру, включая ТСПУ. Если описать суть одним предложением: ECH прячет SNI (Server Name Indication — DNS-имя сервера) внутри зашифрованного блока ClientHello, отрезая DPI-системы от их главного источника информации о том, куда идёт TLS-соединение. Когда ECH станет массовым, целая категория блокировок — SNI-based filtering — перестанет работать.

Эта статья — технический разбор, как ECH устроен внутри, что уже катит Cloudflare и Mozilla, как реагирует ТСПУ в РФ-2026 и что это значит для VPN-индустрии на горизонте 2027.

Зачем понадобился ECH

Чтобы понять ECH, нужно вспомнить дизайн-промах TLS 1.2 и 1.3. В TLS 1.2 (а потом и в 1.3) handshake начинается с ClientHello — пакета, который клиент посылает серверу в открытом виде, до установления зашифрованного канала. В ClientHello передаются параметры будущего соединения: версия TLS, набор cipher suites, supported extensions, и — критически — SNI.

SNI был введён в TLS в 2003 году (RFC 4366), чтобы один IP мог хостить много HTTPS-сайтов: сервер по SNI понимает, на какой именно сайт идёт клиент, и отдаёт правильный certificate. Без SNI virtual hosting на HTTPS был невозможен. Но за 20 лет SNI превратился в главный facility для цензуры: DPI читает SNI и блокирует соединение, не дожидаясь установления TLS.

В РФ ТСПУ уже к 2024 году эффективно использовала SNI-блокировки против известных VPN-доменов (см. наш глоссарий sni-block). Любой сервер vpn.example.com блокировался независимо от протокола внутри, независимо от того, был это OpenVPN или VLESS.

Решение этой проблемы обсуждалось в IETF с 2017 года. Сначала был ESNI (Encrypted SNI, draft-ietf-tls-esni), который пытался шифровать только поле SNI. Но ESNI оставлял утечки через другие fingerprintable поля ClientHello (расширения, cipher suites). Решено было идти дальше: шифровать весь ClientHello — это и есть ECH.

Архитектура ECH

ECH описан в draft-ietf-tls-esni (последний стабильный — draft-18, ноябрь 2024). Технически — это TLS-extension в ClientHello.

Принцип работы:

Сервер (или CDN-провайдер) публикует ECH-ключ в DNS, в специальном record-типе HTTPS (RFC 9460) или SVCB. ECH-ключ — это публичный ключ HPKE (Hybrid Public Key Encryption, RFC 9180), который клиент использует для шифрования.
Клиент при подключении к private.example.com сначала резолвит DNS и получает ECH-ключ. Дальше он создаёт TWO ClientHello: outer и inner.
Outer ClientHello содержит SNI public.example.com (так называемый «outer SNI», или «cover domain» — публично известный неподозрительный домен). Все остальные параметры — generic, не leak’ают информацию о реальном destination.
Inner ClientHello содержит SNI private.example.com, реальные параметры (ALPN, real extensions), и он зашифрован под HPKE с публичным ECH-ключом. Помещается внутри outer ClientHello как ECH-extension.
Server-фронтенд (например, Cloudflare edge) видит outer SNI public.example.com, понимает «это для меня», расшифровывает inner ClientHello, видит реальный SNI private.example.com и роутит соединение туда.

Для DPI это значит: все TLS-соединения, использующие ECH, видятся как соединения на «cover domain» — типичный нейтральный домен вроде cloudflare-ech.com или cloudflareresearch.com. Реальное destination не leak’нет.

Где ECH уже включён в 2026

Cloudflare — pioneer. Включил ECH-experiment в сентябре 2023 для всех своих customers, в production — с начала 2025. Сейчас (май 2026) все сайты за Cloudflare поддерживают ECH автоматически, если клиент его использует. Это десятки миллионов доменов, включая major СМИ, e-commerce, SaaS.

Mozilla Firefox — включил поддержку ECH по умолчанию с Firefox 119 (ноябрь 2023). Включается, когда DNS возвращает HTTPS-record с ECH-key и клиент использует DoH или DoT.

Chrome / Chromium — поддержка с Chrome 117 (сентябрь 2023), но по умолчанию выключена. Включается через chrome://flags/#encrypted-client-hello. По косвенным признакам, Google планирует включить по умолчанию в 2026-2027.

Apple Safari — включил с Safari 17 (сентябрь 2023). По умолчанию включён, если destination поддерживает.

Серверные стеки — поддержка в OpenSSL 3.3+, BoringSSL (production у Google), nginx + дополнительный модуль ngx_http_ssl_module с патчем (пока не в mainline). Caddy — поддержка с версии 2.7.

Реакция ТСПУ — что происходит в РФ-2026

К маю 2026 ТСПУ на ECH-трафик реагирует неоднозначно — разные операторы по-разному.

Сценарий 1 — пропуск. Большинство региональных операторов и часть федеральных пропускают ECH-трафик как обычный TLS. У них в правилах нет специальной обработки. Эффективно для пользователя это значит: если вы подняли свой VPN-сервер за Cloudflare с ECH, ваш SNI невидим для ТСПУ.

Сценарий 2 — частичная блокировка. МТС, МегаФон, частично «Ростелеком» в 2025-2026 начали детектировать ECH-extension и помечать такие соединения как «подозрительные». Активной блокировки нет, но в случае высокой confidence у других слоёв DPI (например, ML-классификатор сработал) — ECH-extension добавляет вес. Это не «блок ECH», а «учёт ECH в общей суматохе».

Сценарий 3 — RST на ECH. Зарегистрированы случаи (преимущественно у Билайна, частично у Tele2) RST-injection на TLS-соединения с ECH-extension. Это не массовая практика, но прецеденты есть. По нашим данным — это тестовый режим одного из вендоров DPI, который не масштабируется на всех абонентов.

Главный политический риск: РКН официально заявил в декабре 2024 (см. публичные пресс-релизы Роскомнадзора), что «массовое распространение средств обхода обязательной фильтрации трафика недопустимо». ECH прямо подпадает под эту формулировку. Когда массовая аудитория переедет на ECH (а это вопрос 2-3 лет), ТСПУ окажется перед выбором: либо разрешить и потерять SNI-видимость, либо блокировать весь ECH-трафик целиком.

Что значит для VPN

ECH — это не VPN. Это TLS-extension, который защищает privacy обычного веб-серфинга, не VPN-туннелей. Но косвенно ECH влияет на VPN-индустрию через четыре механизма.

Первое: SNI-маскировка для VPN-серверов становится бесплатной. Раньше VPN-провайдеры должны были вручную поднимать Reality, который mimics whitelist-домен через proxy первых байт. С ECH это не нужно — достаточно поставить VPN-сервер за Cloudflare (или другой ECH-CDN), и SNI автоматически скрывается. Это сильно упрощает self-hosted VPN — см. нашу статью про подъём VPN на VPS.

Второе: domain fronting возвращается. Domain fronting — техника, когда внешний SNI и реальный Host header отличаются — был эффективно убит в 2018, когда Google и Amazon запретили его на своих CDN. ECH воскрешает domain fronting на новом уровне: outer SNI и inner SNI могут полностью отличаться, и CDN это поддерживает официально.

Третье: TLS-fingerprinting через JA3 теряет значимость. Когда реальный ClientHello зашифрован, ТСПУ может видеть только outer ClientHello — а он generic и одинаков у всех ECH-клиентов. JA3-классификация становится бесполезной для ECH-трафика. Это аннулирует целый слой DPI 2024-2025.

Четвёртое: active probing усложняется. Сейчас ТСПУ может подключиться к подозрительному destination и проверить, есть ли там реальный веб-сервер. С ECH active probing должен правильно подделать ECH-handshake к реальному CDN-фронту, что технически возможно, но требует знания cover domain и работающего ECH-key.

Контрмеры со стороны ТСПУ — варианты 2027

Если ТСПУ хочет противодействовать ECH, у него несколько вариантов, каждый со своими trade-off.

Вариант 1: блокировать весь TLS с ECH-extension. Технически тривиально (sigmatch на presence ECH-extension в ClientHello). Политически — катастрофа: ECH быстро становится default у всех major CDN, блокировка ECH означает блокировку половины интернета. Маловероятно для massовой работы, возможно для тестов.

Вариант 2: блокировать DNS HTTPS-records. Чтобы получить ECH-key, клиент должен резолвить DNS HTTPS-record. Если ТСПУ перехватывает DNS и удаляет HTTPS-record из ответов — клиент не получит ключ и не сможет ECH. Это работает только при использовании plain DNS; при DoH/DoT и DoT — DNS-трафик зашифрован и ТСПУ не может его модифицировать. Контрмера для пользователя — использовать DoH/DoT, что уже массово делают браузеры.

Вариант 3: фильтровать cover domains. Если ТСПУ ведёт список «всех известных cover domains для ECH у CDN», можно блокировать соединения на cover-домены, при этом не ломая остальной трафик. Cloudflare использует cover-домен cloudflare-ech.com — его можно занести в blacklist. Контрмера — Cloudflare ротирует cover-домены, а само ТСПУ не может детектировать ECH без видимости cover-домена.

Вариант 4: behavioral ML. Использовать ML-классификатор на packet timings, размерах TLS-records и других side-channels, не зависящих от SNI. Это уже обсуждается в наших статьях про ML-DPI 2026 и эволюцию ТСПУ.

Практика — как использовать ECH сейчас

Если вы обычный пользователь:

Поставьте Firefox последнюю версию. ECH включён по умолчанию.
Включите DNS-over-HTTPS в настройках Firefox (Settings → Privacy → DNS over HTTPS → Increased Protection). Можно указать Cloudflare 1.1.1.1 или Quad9 9.9.9.9.
Проверьте, что ECH активен на тест-странице Cloudflare: https://crypto.cloudflare.com/cdn-cgi/trace — в выводе должен быть sni=encrypted (без =plaintext).

Если вы держите self-hosted VPN-сервер:

Поставьте сервер за Cloudflare с режимом «Full (Strict)» SSL.
Включите ECH в Cloudflare dashboard (Security → Settings → Encrypted Client Hello).
Используйте клиент с uTLS + ECH (например, sing-box последней версии — поддержка с 1.8+).

Открытые проблемы

ECH не идеален. Несколько известных issues:

Trial decryption. Сервер должен попробовать расшифровать ECH; если ECH-key обновился, а клиент использует старый — handshake падает, нужен fallback на outer SNI. Это leak’ает информацию (factчат failure).
DNS-зависимость. ECH-key приезжает через DNS. Если DNS-резолвер скомпрометирован — атакующий может подменить ключ.
Cover domain leakage. Outer SNI всё равно виден. Если для определённого CDN cover-домен уникален и редок — это уже сигнал.
Performance. ECH добавляет 1-RTT в handshake для key fetching через DNS (если не cached).

Эти issues обсуждаются в IETF и в академической литературе. Главные источники:

Draft draft-ietf-tls-esni-18
Работа «Encrypted Client Hello in the Wild» от Trevisan et al. (NDSS 2024)
Cloudflare research blog: серия публикаций про ECH-deployment
TLS Working Group в IETF datatracker

Прогноз 2027-2028

К концу 2027 ECH станет default’ом в Chrome (по нашему прогнозу), что означает ~70% мирового веб-трафика будут использовать ECH. ТСПУ в РФ будет вынужден выбирать между тремя стратегиями: пропуск (с потерей SNI-видимости), блокировка (с обвалом веб-трафика на CDN) или behavioral DPI (с инвестициями в ML).

Наиболее вероятный сценарий — третий, и это совпадает с уже наблюдаемой эволюцией ТСПУ к ML. ECH ускоряет переход к behavioral DPI, потому что лишает sigmatch его главного хука. Это плохая новость для VPN-сообщества среднесрочно: ECH помогает прятать SNI, но не помогает против ML-классификации поведения.

Контрмера — комбинировать ECH с DAITA, padding и QUIC-протоколами. Только полный stack даёт устойчивость на горизонте 2027+.

Пользовательский опыт после ECH

Что меняется для обычного юзера, когда ECH становится default’ом? Для большинства — ничего видимого. Браузер работает как раньше, страницы открываются, разве что чуть медленнее в первое подключение к сайту (дополнительный DNS-резолв за HTTPS-record). Но под капотом происходит важная перемена.

Privacy-эффект. Provider, оператор, ТСПУ — никто из них не видит, какие конкретно сайты вы посещаете. Они видят только cover-домен — типичный CDN-endpoint. Если у вас Firefox с ECH и DoH, то ваша история веб-серфинга остаётся между вами и CDN (Cloudflare/Apple/etc).

Изменения в реакции цензуры. Когда ECH массово используется, статья 15.1 ФЗ-149 (о блокировках интернет-ресурсов) становится частично невыполнимой. Заблокировать «определённый сайт» через SNI — невозможно с ECH. Можно блокировать только по IP (что блокирует весь CDN) или по DNS-resolution (что обходится DoH).

Корпоративные сети. Не все рады ECH. Корпоративные firewall’ы исторически использовали SNI для policy enforcement: «нельзя ходить на social media» — реализовалось через SNI-блокировку Facebook/Instagram. С ECH это сломается. Корпорации просят TLS-WG включить «enterprise opt-out» — режим, в котором ECH отключается для определённых сетей. Это активно обсуждается в IETF.

Образовательные сети. В РФ есть закон о фильтрации в образовательных учреждениях. ECH на массовой школьной сети означает невозможность фильтровать «детский контент» через SNI. Это создаёт давление либо на отключение ECH в школах, либо на введение transparent proxies с MITM — что технически сложнее и порождает свои уязвимости.

Связанные материалы