SNI и ECH: как закрывают последнее открытое поле TLS

В TLS 1.3 сертификат сервера зашифрован, ключ выводится с forward secrecy, версия и cipher выбираются за один RTT. И всё же первое сообщение ClientHello остаётся самым «разговорчивым» в современном HTTPS — потому что в нём по-прежнему есть поле SNI. Это поле появилось из практической нужды, отлично решило задачу виртуального хостинга и двадцать лет жило компромиссом: содержимое страницы скрыто, но имя домена доступно любому посреднику.

Encrypted ClientHello (ECH) — финальный шаг этого пути. Он спроектирован так, чтобы внедряться постепенно, не ломать существующие сети и решить главную метаданную последнего поколения TLS.

Без ECH                          С ECH
─────────────────                ───────────────────────────
ClientHello {                    Outer ClientHello {
  SNI: bank.example   ←─видно──    SNI: cloud.example   ←─видно (decoy)
  ALPN: h2/h3                       ECH ext: HPKE-encrypted
  cipher_suites                     cipher_suites
}                                 }
                                    └ Inner ClientHello {
                                        SNI: bank.example  ←─зашифровано
                                        ALPN, alpn, ext
                                      }

Откуда взялся SNI: дефицит IPv4 и виртуальный хостинг

До 2003 года один TLS-сервер мог отдать ровно один сертификат. Если на одном IP жили bank.example и shop.example, нужно было два IP-адреса. С ростом веба так быстро упёрлись в лимит IPv4. RFC 4366 и затем RFC 6066 ввели Server Name Indication — расширение TLS, в котором клиент передаёт имя сайта прямо в ClientHello, чтобы сервер выбрал нужный сертификат до его отправки.

Это работало настолько хорошо, что сегодня практически все CDN держат тысячи доменов на одном anycast-IP. Cloudflare, Fastly, Akamai раздают по одному IP-адресу контент сотен тысяч сайтов. Без SNI современный HTTPS-веб был бы технически невозможен — или потребовал бы IPv6 десять лет назад.

Механика SNI: как поле живёт в ClientHello

SNI — это TLS-расширение типа 0x0000. В нём передаётся HostName в ASCII (или Punycode для IDN). Структура минимальная: длина списка → тип имени (всегда 0) → длина → собственно строка. Никакой защиты, никакой обёртки: символы домена идут открытым текстом в первом же сообщении после трёх пакетов TCP-handshake.

Это удобно для CDN, для load balancer'ов вроде HAProxy и Envoy, для anycast-адресов. И это же делает SNI идеальной точкой для классификации трафика: одно поле, точное значение, никакой статистики не нужно.

ESNI: почему первая попытка не взлетела

В 2018 году появился черновик ESNI — Encrypted SNI. Идея была проще ECH: брать только поле server_name, шифровать его ключом из DNS-записи, отправлять в отдельном расширении. Cloudflare включал ESNI в продакшене, Firefox поддерживал за флагом.

Проблем оказалось две. Первая — слишком тесная связь с DNS: сетевое оборудование, которое умело читать имя из SNI, легко переходило к чтению имени из DNS-запроса. Вторая — fingerprinting: соединение с ESNI настолько отличалось от обычного, что само наличие ESNI становилось маркером. К 2020 году IETF признал концепцию недостаточной и переработал её в ECH.

Архитектура ECH: outer, inner и HPKE

ECH (RFC, развивающийся черновик с 2025 года) разделяет ClientHello на две части. Снаружи остаётся Outer ClientHello с заведомо несекретным SNI — обычно это публичное имя CDN типа cloudflare-ech.com. Внутри лежит Inner ClientHello с настоящим SNI и всеми чувствительными расширениями, зашифрованный схемой HPKE (Hybrid Public-Key Encryption из RFC 9180).

Ключ HPKE — это ECHConfig, и берётся он из DNS HTTPS-записи (RFC 9460). Когда браузер делает dig example.com HTTPS, он получает не только список ALPN и подсказки IP, но и публичный ключ ECH для этого домена. Дальше клиент шифрует Inner ClientHello этим ключом и кладёт результат в расширение Outer.

Сервер, который поддерживает ECH, расшифровывает inner и продолжает handshake так, как будто SNI был сразу настоящий. Если ECH не включён, сервер игнорирует расширение и работает по Outer SNI — и тогда возможен retry с правильным ключом.

Что нужно для развёртывания ECH

Для работающего ECH мало просто включить опцию на сервере. Нужно совпадение нескольких условий:

• Шифрованный DNS у клиента. Иначе посредник прочитает домен в обычном UDP/53-запросе и SNI спрятать смысла нет. На практике это DoH в браузере или DoT/DoQ на уровне ОС.
• HTTPS DNS-записи на домене с актуальным ECHConfig. Cloudflare, Fastly и крупные публичные authoritative-серверы это уже умеют.
• Anycast-IP с большим anonymity set. ECH прячет SNI, но не IP. Чем больше доменов живёт на одном IP, тем меньше пользы от знания этого IP — поэтому ECH в первую очередь развёртывают CDN.
• Поддержка на сервере. nginx-quic, OpenSSL 3.4+, BoringSSL умеют ECH. Apache и старые версии — пока нет.
• Свежий клиент. Chrome 117+ и Firefox 118+ поддерживают ECH, но включают его постепенно по флагам.

Что ECH не делает

ECH прячет SNI и оставшуюся часть Inner ClientHello, но не маскирует сам факт TLS-соединения, не скрывает IP сервера и не меняет паттерн трафика. Если у CDN на одном anycast-IP живут тысячи доменов, ECH создаёт большой набор «неотличимых» соединений; если IP уникальный — знание IP остаётся равносильно знанию домена. Размеры и тайминги пакетов тоже остаются прежними, поэтому статистические методы продолжают работать.

Границы видимости детальнее разбираются в статье про HTTPS и метаданные.

Где это сейчас и куда движется

На середину 2026 года ECH уже включён по умолчанию в Cloudflare для значительной части своих доменов; Fastly экспериментирует на отдельных клиентах; Apple включил ECH в Safari 17/18; Mozilla — в Firefox 132 для DoH-пользователей; Chrome — за флагом для всех. На стороне сервера BoringSSL и nginx-quic поддерживают ECH в продакшене.

Долгосрочно ECH меняет два вещи. Во-первых, классификация на уровне SNI становится менее точной, и системы анализа трафика будут смещаться к статистическим признакам и JA4 fingerprint'ам. Во-вторых, DNS становится новой точкой видимости: если он не зашифрован, ECH теряет смысл. Поэтому соседняя тема — DoH и DoT, без которых ECH работает только наполовину.

Итого

SNI родился как инженерный компромисс эпохи массового HTTPS и спас IPv4 от коллапса. ECH — это не «магическое решение всех проблем приватности», а аккуратное продолжение той же логики: то, что не нужно сети для маршрутизации, должно ехать внутри криптографии. Развёртывание идёт постепенно и требует совпадения серверов, DNS и клиентов, но направление однозначное — последний открытый текст в TLS постепенно уходит в прошлое.