Encrypted Client Hello (ECH): как работает шифрование SNI и зачем это нужно

Вы когда-нибудь задумывались, почему ваш интернет-провайдер или корпоративный администратор может знать, какие сайты вы посещаете, даже если вы используете HTTPS? Ответ кроется в маленькой, но критической детали первых миллисекунд соединения - SNI (Server Name Indication). Это поле всегда передавалось в открытом виде, позволяя любому посреднику видеть, куда вы направляетесь. Технология Encrypted Client Hello (ECH) призвана закрыть эту уязвимость раз и навсегда. В этой статье мы подробно, от А до Я, разберём, как работает ECH, из каких этапов состоит, какие у него есть ограничения и что он означает для обычных пользователей, владельцев сайтов и систем фильтрации трафика.

Почему SNI - это проблема, которую мы игнорировали десятилетиями

Чтобы оценить прорыв ECH, нужно сначала понять старую архитектуру TLS. TLS (Transport Layer Security) - это протокол, который обеспечивает шифрование данных между вашим браузером и веб-сервером. Он работает поверх TCP, и каждое новое соединение начинается с так называемого "рукопожатия" (handshake). В самом начале этого рукопожатия браузер отправляет сообщение ClientHello. В этом сообщении есть список поддерживаемых шифров, версий TLS, случайные данные для генерации ключей и - поле SNI (Server Name Indication). SNI содержит доменное имя сайта, который вы хотите открыть (например, supersite.com). Зачем это нужно? Из-за того, что на одном IP-адресе может размещаться множество сайтов (виртуальный хостинг), сервер должен знать, какой именно сайт показать, ещё до того, как начнётся шифрование. Это "знание" и передаётся через SNI.

Проблема в том, что всё сообщение ClientHello, включая SNI, до недавнего времени передавалось в открытом виде. Так, любой, кто имеет доступ к линии (провайдер, сетевой администратор, владелец точки Wi-Fi), мог видеть, какие сайты открывают пользователи. Да, содержимое страниц и пароли были зашифрованы, но сам факт посещения определённого ресурса оставался открытым.

Что такое ECH и чем он отличается от предшественника ESNI

Encrypted Client Hello (ECH) - это расширение для TLS 1.3, которое шифрует всё сообщение ClientHello, включая SNI, другие расширения и даже часть параметров согласования. Разработка ECH шла несколько лет, и до него существовала экспериментальная технология ESNI (Encrypted Server Name Indication), которая шифровала только само поле SNI, но оставляла остальную часть ClientHello открытой. ESNI был хорош, но его можно было обойти, анализируя другие поля (например, список поддерживаемых шифров или расширения), которые нередко были уникальны для конкретного сайта или сервиса. ECH пошёл дальше: он полностью шифрует весь ClientHello за несколькими исключениями (версия TLS, несколько служебных байтов). По сути, ECH оставляет снаружи только "оболочку"-пустышку, а всё существенное скрывает внутри зашифрованной капсулы. Это сделано для того, чтобы у посредника не оставалось никаких зацепок, по которым можно было бы определить целевой сайт.

Как работает ECH: пошаговое техническое описание

Теперь перейдём к деталям. Процесс установки ECH-соединения можно разбить на несколько этапов. Я опишу их максимально подробно, избегая излишней математики, но с сохранением необходимой строгости.

Публикация криптографического ключа в DNS

Всё начинается с владельца сайта. Он генерирует пару ключей: закрытый (приватный) и открытый (публичный). Открытый ключ вместе с параметрами шифрования (например, идентификатор конфигурации) он публикует в DNS-записи специального типа - HTTPS (или SVCB). Эта запись имеет параметр ech, который содержит закодированный открытый ключ. Пример записи: supersite.com. 3600 IN HTTPS 1 . alpn="h2" ech="AEX+...". Ключ обычно имеет длину 32 байта (для кривой X25519) или 48 байт (для P-256). Также публикуется так называемый "публичный домен" (public name), который будет использоваться во внешнем, незашифрованном ClientHello в качестве маски. Этот домен обычно принадлежит крупному CDN или хостинг-провайдеру и не несёт смысловой нагрузки. Публикация ключа в DNS - это единственное, что требует предварительного изменения инфраструктуры сайта. Без неё ECH работать не будет.

Получение ключа браузером (с помощью DNS-over-HTTPS)

Когда пользователь вводит адрес сайта, браузер выполняет DNS-запрос, чтобы получить IP-адрес. Но современные браузеры (Chrome, Firefox) также автоматически запрашивают и DNS-записи типа HTTPS. Чтобы защитить сам процесс получения ключа от подмены (атаки "человек посередине"), браузеры используют DNS-over-HTTPS (DoH) - шифрованное соединение с DNS-сервером провайдера или публичным резолвером (например, Cloudflare 1.1.1.1). Если DoH недоступен, браузер может получить ключ и по обычному DNS, но тогда он уязвим для подмены. Важно: запрос HTTPS-записи выполняется параллельно с обычным A/AAAA-запросом, чтобы не увеличивать задержку. Если ключ успешно получен, браузер сохраняет его в локальный кэш на время TTL записи.

Формирование "двойного" ClientHello (внешний + внутренний)

Теперь, когда у браузера есть публичный ключ, он создаёт два сообщения ClientHello. Внешний (Outer) ClientHello - это то, что будет отправлено по сети в открытом виде. В нём: версия TLS (только TLS 1.3), несколько случайных байт, и, самое главное, поле SNI, которое содержит не настоящий домен, а "публичный домен", указанный в DNS-записи. Также внешнее сообщение содержит специальное расширение encrypted_client_hello, в котором будет лежать зашифрованная капсула. Внешнее сообщение намеренно выглядит как стандартное, не вызывающее подозрений у DPI-систем. Внутренний (Inner) ClientHello - это настоящее сообщение, содержащее истинный SNI, список поддерживаемых шифров, расширения и другие параметры соединения. Внутреннее сообщение шифруется симметричным ключом, полученным из публичного ключа сайта с использованием алгоритма ECDH (Elliptic Curve Diffie-Hellman). Получившийся зашифрованный блок помещается в расширение encrypted_client_hello внешнего сообщения. Важно: внутреннее сообщение также содержит "защищённый" вариант расширений, которые могут быть чувствительны к утечке, например, настройки сжатия или протоколы ALPN.

Отправка на сервер и расшифровка

Браузер отправляет внешний ClientHello на сервер. Сервер, получив его, обнаруживает расширение encrypted_client_hello. Он использует свой приватный ключ, соответствующий опубликованному публичному ключу, чтобы выполнить этап ECDH и расшифровать внутренний ClientHello. Если расшифровка успешна, сервер извлекает из внутреннего сообщения истинный SNI и продолжает обычное TLS-рукопожатие (отправляет ServerHello, сертификаты, согласование шифров и т.д.). Всё остальное соединение ничем не отличается от обычного TLS 1.3. Если расшифровка не удалась (например, браузер использовал устаревший ключ или не тот публичный домен), сервер может отправить специальный ответ с типом ech_required и предложить браузеру повторить попытку с корректной конфигурацией. В этом случае браузер запрашивает свежую DNS-запись и повторяет весь процесс. Такое поведение предусмотрено спецификацией и повышает отказоустойчивость.

Завершение рукопожатия

После того как сервер расшифровал внутренний ClientHello, процесс становится неотличимым от обычного TLS 1.3. Сервер и клиент согласовывают шифры, обмениваются сертификатами, генерируют ключи сессии. Вся последующая переписка (данные HTTP) шифруется как обычно. Пользователь не видит никакой разницы. Единственное, что может измениться - если сервер не поддерживает ECH или браузер не смог получить ключ, соединение установится в обычном режиме, без шифрования SNI. Таким образом, ECH не ломает существующие сайты - он просто добавляет дополнительный уровень приватности там, где это возможно.

Ключевые технические термины, которые нужно знать

Чтобы глубже понимать ECH, полезно знать несколько терминов.

TLS 1.3 - версия протокола Transport Layer Security, выпущенная в 2018 году. Она упростила рукопожатие, убрала устаревшие криптографические алгоритмы и заложила основу для расширений вроде ECH. Без TLS 1.3 ECH был бы невозможен, так как в старых версиях структура ClientHello не позволяла безопасно скрыть расширения.

SNI - Server Name Indication, поле в ClientHello, содержащее имя сервера. Это то самое поле, которое ECH и прячет.

DNS-over-HTTPS (DoH) - технология, которая шифрует DNS-запросы, передавая их по протоколу HTTPS. Используется браузерами для безопасного получения ECH-ключей. Альтернатива - DNS-over-TLS (DoT), но DoH распространён шире.

ECDH (Elliptic Curve Diffie-Hellman) - криптографический алгоритм, позволяющий двум сторонам вычислить общий секретный ключ, имея публичные ключи друг друга. Именно он используется внутри ECH для шифрования внутреннего ClientHello.

Public name - публичное имя домена, которое указывается во внешнем ClientHello вместо настоящего. Обычно это общий домен CDN, например, cloudflare-ech.com. Несмотря на то, что внешнее имя видно всем, оно не раскрывает целевой сайт.

Пример работы ECH на реальном сайте (воображаемый сценарий)

Представьте, что вы заходите на сайт mysecretblog.com, который использует ECH через Cloudflare. Ваш браузер сначала делает запрос DoH к серверу Cloudflare (1.1.1.1) и получает HTTPS-запись для mysecretblog.com. В записи указан публичный ключ и публичное имя cloudflare-ech.com. Затем браузер формирует внешний ClientHello с SNI = cloudflare-ech.com и зашифрованный внутренний ClientHello с SNI = mysecretblog.com. Этот пакет отправляется на IP-адрес сервера. Сервер Cloudflare принимает его, видит, что внешний SNI указывает на Cloudflare, но расшифровывает капсулу своим ключом и определяет, что реальный запрос предназначен для mysecretblog.com. Затем Cloudflare проксирует соединение к реальному серверу блога. Для провайдера, который видит только внешнее сообщение, кажется, что пользователь общается с cloudflare-ech.com, а не с конкретным блогом. Так достигается приватность.

Если бы провайдер попытался заблокировать mysecretblog.com по SNI, он бы не смог этого сделать, поскольку SNI не виден. Единственное, что он может - заблокировать весь IP-адрес Cloudflare или начать блокировать сам факт использования ECH, что сейчас и происходит в России. Таким образом, ECH переносит битву с уровня контента на уровень протокола.

Поддержка ECH в браузерах и серверном ПО

На момент написания статьи (середина 2026 года) поддержка ECH уже реализована в большинстве современных браузеров. Google Chrome (начиная с версии 121) включает ECH по умолчанию. Mozilla Firefox (с версии 123) также поддерживает ECH, но в некоторых сборках для России функция может быть отключена программно. Яндекс.Браузер, судя по тестам, пока не имеет полной поддержки ECH. Microsoft Edge, будучи основанным на Chromium, унаследовал поддержку от Chrome. На стороне серверов главным драйвером стала компания Cloudflare, которая включила ECH для всех сайтов ещё в 2024 году. Также экспериментальные сборки Nginx (начиная с версии 1.29.4) и Apache (с патчами) позволяют включать ECH. OpenSSL 4.0 имеет экспериментальную поддержку ECH через специальные API.

Проблемы и ограничения ECH

Технология ECH, несмотря на свою элегантность, не лишена недостатков. Во-первых, она требует, чтобы DNS-запрос для получения ключа был защищён (DoH). Если DoH не используется, возможна атака подмены ключа. Во-вторых, ECH не скрывает IP-адрес сервера. Адрес назначения всегда виден, так как пакеты TCP/IP не могут быть зашифрованы на этом уровне. Поэтому, если злоумышленник знает, что определённый IP принадлежит нежелательному сайту, он может заблокировать весь IP. В-третьих, ECH может быть обнаружен по наличию расширения encrypted_client_hello. DPI-системы, не умея расшифровать содержимое, легко детектят сам факт использования расширения. И как показывает практика, некоторые государства (включая Россию) начали блокировать любые соединения с ECH, считая их потенциально вредными. Это привело к парадоксальной ситуации: сайты, которые заботились о приватности пользователей, стали недоступны для них же.

Ещё одна проблема - усложнение отладки сетевых проблем. Инженеры не могут просто перехватить трафик на уровне SNI. Также корпоративные сетевые экраны, которые полагаются на SNI для контроля доступа, теряют эту возможность. Это вынуждает компании либо полностью блокировать ECH, либо переходить на более сложные и дорогостоящие системы анализа поведения трафика. В некоторых организациях уже ввели политику "отключить ECH в корпоративных браузерах" через групповые политики или путём блокировки DoH.

ECH и российское законодательство: конфликт, которого нельзя было избежать

Российская система фильтрации ТСПУ (Технические средства противодействия угрозам) долгое время работала именно на основе анализа SNI. Блокировка конкретного сайта по SNI была простой и дешёвой. Появление ECH разрушило эту схему. Поэтому реакция РКН была предсказуемой: начались массовые блокировки сайтов, которые используют ECH (в первую очередь тех, что размещены на Cloudflare). К концу 2024 года были выпущены рекомендации "отказаться от использования TLS ECH", так как это средство обхода ограничений. Владельцам сайтов в России пришлось выбирать: либо оставаться с ECH и терять доступность для российских пользователей, либо отключать ECH (на сервере или через настройки CDN) и жертвовать приватностью. Некоторые хостинг-провайдеры начали намеренно использовать старые версии OpenSSL и Nginx без поддержки ECH, чтобы избежать проблем.

Практические рекомендации для владельцев сайтов

Если ваш сайт работает на российскую аудиторию, я рекомендую отключить ECH. Это можно сделать несколькими способами. Если у вас VPS, зайдите в конфиг Nginx и добавьте ssl_ech off; в блок server. Для Apache: SSLECH off. Если вы для сайта РФ до сих пор используете Cloudflare, то большинство посетителей могут открыть ваш сайт только с ВПН (РКН летом 2025 года перешёл к тотальной блокировке Cloudflare, независимо от того, включен ECH на сайтах или нет).

Если вы на shared-хостинге, обратитесь в техподдержку с просьбой отключить ECH на сервере. Если ваш сайт ориентирован на зарубежную аудиторию, можете оставить ECH включённым - это повысит приватность. В любом случае, помните, что ECH может быть обнаружен и заблокирован, поэтому лучше не полагаться на него как на основное средство обхода блокировок.

Часто задаваемые вопросы об ECH

ECH делает меня анонимным в интернете?
Нет. ECH скрывает только имя сайта. Ваш IP-адрес, браузер и другие параметры по-прежнему видны.

Почему некоторые сайты перестали открываться?
Возможно, эти сайты включили ECH, а ваш провайдер блокирует ECH-трафик (вернее, не провайдер, а РКН через оборудование, которое установлено у провайдера и через которое он этот трафик фильтрует). Попробуйте временно отключить ECH в браузере (флаг chrome://flags/#encrypted-client-hello).

Как проверить, использует ли сайт ECH?
Можно использовать команду dig +short supersite.com HTTPS (подставьте название своего сайта) - наличие параметра ech говорит о публикации ключа.

Будущее ECH: что дальше?

Технология ECH продолжит развиваться. Уже сейчас ведутся работы по интеграции ECH с другими протоколами, например, с QUIC и HTTP/3. Также рассматривается возможность использования ECH для защиты не только SNI, но и других метаданных, таких как метки времени или размеры пакетов. Однако, как это часто бывает, противодействие тоже не стоит на месте. DPI-системы учатся детектировать ECH даже по мелким артефактам (например, по необычному размеру пакетов). Вероятно, в скором времени появятся новые методы маскировки ECH под обычный трафик.

В России же, скорее всего, борьба с ECH продолжится на уровне блокировки IP-диапазонов CDN и хостингов, которые его поддерживают.