Encrypted Client Hello: что меняет ECH в приватности HTTPS

Какая часть HTTPS долго оставалась видимой

HTTPS давно защищает содержимое страницы: пароль, текст формы, cookie сессии, тело запроса и ответ сайта. Но до появления Encrypted Client Hello у соединения оставалась заметная особенность: на раннем этапе TLS-клиенту нужно было сообщить серверу, к какому имени он обращается. Это поле связано с SNI и помогает серверу выбрать нужный сертификат, когда на одном IP размещено несколько сайтов.

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

Важно не превращать ECH в миф. Он не скрывает сам факт сетевого соединения, не убирает IP-адрес сервера из маршрута и не заменяет VPN. Он уменьшает объём информации, который можно получить из TLS-приветствия. Для базовой границы между SNI и ECH полезен материал SNI, ECH и приватность домена в HTTPS: там удобнее начать с вопроса, почему имя сайта вообще появлялось в начале TLS.

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

ECH шифрует внутренний ClientHello. Упрощённо это выглядит так: браузер получает параметры для ECH через DNS-запись, формирует внешний ClientHello с технической оболочкой и прячет настоящие детали во внутренней зашифрованной части. Сервер, который поддерживает ECH и имеет нужные ключи, расшифровывает эту часть и продолжает обычное TLS-соединение.

Из-за этого наблюдатель на пути уже не должен видеть реальное имя сайта в привычном SNI. Но он всё равно может видеть IP-адрес, время соединения, объём данных, DNS-запросы в некоторых конфигурациях и сам факт обращения к инфраструктуре. Поэтому ECH — это улучшение приватности HTTPS, а не универсальная маска для всей сетевой активности.

ECH также зависит от поддержки на нескольких уровнях: браузер, DNS, CDN или серверная инфраструктура, сертификаты и корректная публикация параметров. Если один слой не готов, соединение может перейти на обычное поведение или не дать ожидаемого эффекта. Здесь полезна связка с материалом как работают TLS, HTTPS и VPN вместе: ECH живёт внутри HTTPS-логики, а не вместо неё.

Почему DNS остаётся рядом с ECH

ECH часто обсуждают вместе с DNS, потому что параметры для него публикуются через DNS-записи HTTPS/SVCB. Если DNS-запрос остаётся открытым, часть приватности всё равно может теряться на другом слое. Пользователь не увидит старый SNI, но наблюдатель может понять домен через обычный DNS-запрос. Поэтому ECH особенно хорошо раскрывается вместе с защищённым DNS: DoH, DoT или другим аккуратным резолвингом.

Здесь легко ошибиться в ожидании. ECH не обязан чинить DNS. Он не делает резолвер доверенным, не меняет политику браузера и не гарантирует, что все приложения используют один и тот же DNS-механизм. Браузер может поддерживать ECH, а системная утилита или другое приложение — нет. Сайт может быть доступен через CDN с ECH, а соседний поддомен — без него.

Практический вывод: проверять нужно не «включился ли ECH вообще», а где именно он работает. Один домен может поддерживать ECH, второй — нет; один браузер может использовать нужную схему, другой — нет; одна сеть может пропускать защищённый DNS, другая — вмешиваться в резолвинг. Для приватности это важнее, чем общий рекламный статус «ECH ready».

Где ECH не помогает

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

ECH не исправляет ошибки сертификата. Если цепочка неполная, сертификат выпущен не на то имя или сервер отдаёт неправильный набор промежуточных сертификатов, приватность TLS-приветствия не спасает доступность сайта. Для таких случаев нужен отдельный разбор incomplete certificate chain, потому что проблема лежит в доверии к сертификату, а не в шифровании ClientHello.

ECH также не защищает пользователя от входа в аккаунт, cookies, fingerprint браузера, аналитики на сайте и поведения самой страницы. HTTPS и ECH отвечают за сетевой и криптографический слой. Они не отменяют идентификаторы внутри приложения. Поэтому грамотная статья про ECH должна говорить не только о том, что скрывается, но и о том, что остаётся видимым.

Как проверить поддержку без самообмана

Сначала нужно выбрать конкретный домен, а не проверять абстрактный «интернет». Затем открыть его в современном браузере, который поддерживает ECH, и убедиться, что DNS-настройки не ломают публикацию HTTPS/SVCB-записей. После этого можно проверить сетевой след через инструменты браузера, тестовые страницы провайдера или диагностику DNS. Для обычного пользователя достаточно понять: один сайт может работать с ECH, а другой нет.

Для владельца сайта проверка начинается с инфраструктуры. Нужно убедиться, что поставщик DNS и CDN поддерживает ECH, что записи опубликованы корректно, что сертификаты совпадают с нужными именами, а старые клиенты не ломаются. Особенно важно тестировать не только главную страницу, но и поддомены: кабинет, API, статические файлы, почту и технические страницы могут жить в разных местах.

Кейс: у проекта включили ECH на основном домене через CDN, но кабинет остался на отдельном поддомене без поддержки. В рекламном описании написали «ECH включён», а пользовательская проверка показывала смешанный результат. После аудита домены разделили: для главной страницы оставили ECH через CDN, а для кабинета отдельно проверили TLS, сертификат и DNS. Вывод: ECH оценивают по конкретным именам, а не по общей галочке в панели.

Что ECH меняет, а чего не делает

Участок TLS

VPN и HTTPS работают на разных уровнях. SSL VPN задаёт транспортную схему, а ECH относится к определённой части TLS-обмена. Сертификат VPN сервера всё равно проверяется клиентом. Ошибка сертификата VPN не исправляется включением ECH.

Маршрут трафика

VPN соединение определяет путь трафика при работающем туннеле. VPN меняет IP только для соответствующих направлений. DNS через VPN проверяют отдельно. Раздельное туннелирование VPN может оставить приложения вне туннеля, и ECH этого не меняет.

Сайт и провайдер

Сайт VPN сервиса продолжает видеть обычные данные своей сессии. Что видит провайдер при использовании VPN зависит от маршрута, конечных адресов и протоколов. Домен для VPN сервера не скрывается одной настройкой ECH. Профиль VPN остаётся необходимым для самого подключения.

Проверка

Проверить VPN соединение нужно штатным клиентом. Проверка утечки ВПН оценивает маршрут, но не доказывает поддержку ECH по всей цепочке. Безопасный VPN требует совместимых версий клиента и сервера. Не объявляйте функцию включённой только по наличию TLS.

В этой схеме серверная часть — vpn сервер; рядом разобраны профиль vpn и клиентские шаги для vpn подписка и vpn для iphone.

FAQ по Encrypted Client Hello

ECH скрывает название сайта полностью?

Он скрывает чувствительную часть TLS-приветствия, где раньше мог светиться SNI. Но IP-адрес, DNS-слой, время соединения и поведение сайта могут оставаться источниками информации.

Нужен ли ECH, если уже есть HTTPS?

Да, потому что HTTPS защищает содержимое соединения, а ECH уменьшает утечку имени на этапе TLS-приветствия. Это улучшение внутри HTTPS, а не отдельная замена.

Почему ECH часто зависит от CDN?

Потому что на практике поддержку ECH проще развернуть там, где инфраструктура управляет DNS, сертификатами и TLS-терминацией для множества доменов.

Можно ли считать ECH заменой VPN?

Нет. VPN меняет маршрут и внешний IP, а ECH работает внутри HTTPS-соединения и закрывает конкретную часть TLS-метаданных.

Можно ли сочетать ECH и VPN соединение на одном устройстве?

Да, они относятся к разным уровням защиты. ECH, когда поддерживается участниками обмена, скрывает часть TLS ClientHello, а VPN переносит выбранный трафик внутри туннеля. Их совместное использование не отменяет видимость IP на соответствующих участках и не скрывает действия от сайта после входа в аккаунт.

Encrypted Client Hello заменяет VPN для приватности?

ECH не создаёт туннель для остальных приложений и не отменяет наблюдаемые IP-адреса или объём обмена. Сопоставьте VPN соединение с областью действия ECH, а SSL VPN — с используемым транспортом. Наличие TLS само по себе не подтверждает поддержку ECH на всей цепочке подключения.