ECH (Encrypted ClientHello)

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

ClientHello — это начальное сообщение, отправляемое клиентом (например, браузером) серверу при установлении TLS-соединения. Оно содержит важные данные, такие как:

• Версия TLS.
• Поддерживаемые шифры (cipher suites).
• Идентификатор сервера (SNI, Server Name Indication), который указывает, к какому домену клиент хочет подключиться.
• Другие параметры, такие как поддерживаемые расширения TLS.

SNI передаётся в открытом виде, что делает его уязвимым для перехвата. Злоумышленники, пассивные наблюдатели или цензоры могут видеть, к какому домену обращается пользователь, даже если само содержимое соединения зашифровано. Это может использоваться для:

• Отслеживания активности пользователей.
• Блокировки доступа к определённым сайтам.
• Анализа трафика для выявления целевых серверов.

ECH решает эту проблему, шифруя ClientHello, включая SNI, чтобы предотвратить утечку метаданных.

ECH основывается на механизме, предложенном в проекте ESNI (Encrypted Server Name Indication), но является его более продвинутой и гибкой версией. Вот основные этапы работы ECH:

1. Разделение ClientHello на внешнюю и внутреннюю части:
   • Внешний ClientHello (Outer ClientHello): Это сообщение, которое отправляется в открытом виде. Оно содержит минимально необходимую информацию для установления соединения, включая "фиктивное" значение SNI, которое не раскрывает реальный домен.
   • Внутренний ClientHello (Inner ClientHello): Это зашифрованная часть, содержащая настоящие данные, включая реальный SNI и другие чувствительные параметры.
2. Шифрование внутреннего ClientHello:
   • Клиент получает открытый ключ шифрования от сервера (или связанного с ним сервиса) через DNS. Этот ключ публикуется в DNS-записи типа TLSA или HTTPS (в формате SVCB/HTTPS).
   • Внутренний ClientHello шифруется с использованием этого открытого ключа, что делает его недоступным для посторонних наблюдателей.
3. Отправка и обработка:
   • Клиент отправляет внешний ClientHello с зашифрованным внутренним ClientHello как расширением.
   • Сервер (или прокси, поддерживающий ECH) расшифровывает внутренний ClientHello с использованием соответствующего закрытого ключа и обрабатывает запрос, как если бы он получил обычный ClientHello.
4. Обратная совместимость:
   • Если сервер не поддерживает ECH, он игнорирует зашифрованное расширение и продолжает обработку на основе внешнего ClientHello. Это позволяет ECH быть обратно совместимым с TLS 1.3.

• Протокол: ECH — это расширение TLS 1.3, описанное в черновике IETF (Internet Engineering Task Force). Оно не применимо к более ранним версиям TLS.
• Ключевая особенность: ECH использует HPKE (Hybrid Public Key Encryption) — криптографический протокол, который комбинирует симметричное и асимметричное шифрование для обеспечения высокой безопасности и эффективности.
• DNS-интеграция: ECH требует, чтобы сервер публиковал свои ключи шифрования в DNS. Это делается через записи HTTPS/SVCB, которые также могут содержать информацию о приоритетных серверах или альтернативных протоколах.
• Обработка на стороне сервера: ECH часто используется в связке с инфраструктурой, такой как CDN (Content Delivery Networks), где фронтальный сервер (например, Cloudflare) расшифровывает ECH и перенаправляет запрос к нужному бэкенду.

1. Конфиденциальность:
   • Скрывает SNI и другие метаданные ClientHello, делая невозможным определение целевого домена без расшифровки.
   • Защищает от цензуры, основанной на анализе SNI.
2. Безопасность:
   • Уменьшает поверхность атаки, связанную с утечкой метаданных.
   • Усложняет целевые атаки, такие как перехват трафика или подмена сертификатов.
3. Гибкость:
   • Поддерживает сложные сценарии, такие как работа через CDN или прокси, где несколько доменов обслуживаются одним IP-адресом.
   • Обеспечивает обратную совместимость с серверами, не поддерживающими ECH.

1. Зависимость от DNS:
   • Для работы ECH требуется доступ к DNS-записям с ключами шифрования. Если DNS-записи заблокированы или подделаны, ECH может быть неэффективным.
   • Рекомендуется использовать защищённые протоколы DNS, такие как DNS-over-HTTPS (DoH) или DNS-over-TLS (DoT), для предотвращения манипуляций.
2. Ограниченная поддержка:
   • На момент 2025 года ECH всё ещё находится на стадии внедрения. Поддержка есть в некоторых браузерах (например, Firefox, Chrome) и серверах (Nginx, Apache с модулями), но не повсеместно.
   • Для полной работы требуется, чтобы клиент, сервер и инфраструктура (например, CDN) поддерживали ECH.
3. Сложность внедрения:
   • Настройка ECH требует дополнительных усилий со стороны администраторов серверов, включая публикацию DNS-записей и управление ключами.
   • Возможны проблемы с отладкой, так как зашифрованные метаданные сложнее анализировать.
4. Потенциальные атаки:
   • Если злоумышленник получит доступ к закрытому ключу ECH (например, через компрометацию сервера), он сможет расшифровать внутренний ClientHello.
   • Некоторые цензоры могут блокировать соединения, использующие ECH, просто на основании наличия этого расширения.

• Стандартизация: ECH разрабатывается в рамках IETF и находится на стадии черновика (draft-ietf-tls-esni). Ожидается, что он станет частью стандарта TLS в будущем.
• Поддержка:
  • Браузеры: Firefox и Chrome (и его производные, такие как Edge) начали экспериментальную поддержку ECH. Safari и другие браузеры постепенно добавляют поддержку.
  • Серверы и CDN: Cloudflare, Fastly и некоторые другие крупные CDN поддерживают ECH. Серверы, такие как Nginx, добавили поддержку через плагины.
  • Операционные системы: Некоторые ОС, такие как iOS и Android, начинают интегрировать ECH в свои сетевые стеки.
• Практическое использование: ECH чаще всего используется на сайтах, требующих высокой конфиденциальности, таких как банковские сервисы, платформы для обмена сообщениями или сайты, подверженные цензуре.

Предположим, пользователь хочет посетить сайт example.com:

1. Браузер запрашивает DNS-запись example.com и получает публичный ключ ECH через HTTPS-запись.
2. Браузер формирует внешний ClientHello с фиктивным SNI (например, cdn-provider.com) и зашифрованным внутренним ClientHello, содержащим реальный SNI (example.com).
3. Сервер CDN (например, Cloudflare) расшифровывает внутренний ClientHello, узнаёт, что запрос предназначен для example.com, и перенаправляет его на соответствующий сервер.
4. Соединение устанавливается, и внешний наблюдатель видит только фиктивное SNI, не зная, к какому домену на самом деле подключается пользователь.

ECH — это важный шаг к полной конфиденциальности сетевых соединений. В будущем ожидается:

• Более широкое внедрение в браузеры, серверы и инфраструктуру.
• Интеграция с другими технологиями, такими как QUIC и HTTP/3, для дальнейшего повышения скорости и безопасности.
• Улучшение стандартов DNS для упрощения публикации ключей ECH.
• Возможное включение ECH в стандарт TLS как обязательного компонента.

ECH — это мощный инструмент для защиты конфиденциальности пользователей в интернете, устраняющий одну из последних уязвимостей TLS — утечку метаданных через SNI. Хотя технология всё ещё находится на стадии внедрения, её поддержка растёт, и она уже используется крупными игроками в интернете. Для пользователей и администраторов, заботящихся о приватности, ECH становится важным элементом безопасной сетевой инфраструктуры.