Блог/Приватность
Приватность19 июля 2026· 9 мин чтения

ECH и DoH: как браузер скрывает SNI и DNS от провайдера

Когда вы открываете сайт по HTTPS, провайдер всё равно видит, куда вы идёте. ECH и DoH — два дополняющих друг друга механизма, которые закрывают эту брешь. Разбираемся, как они работают в 2026 году, что такое GREASE ECH и почему этого по-прежнему недостаточно для полной приватности.

Что видит провайдер при HTTPS-соединении

Многие думают: раз соединение зашифровано и в адресной строке замок — провайдер ничего не видит. Это не так.

При установке HTTPS-соединения браузер сначала выполняет DNS-запрос (узнаёт IP-адрес сайта), а потом отправляет TLS ClientHello — пакет, содержащий имя сайта в открытом виде. Это поле называется SNI (Server Name Indication).

Что видно провайдеру
Даже для зашифрованного HTTPS-сайта провайдер видит: DNS-запрос с именем домена, IP-адрес сервера, объём трафика и время соединения, а также SNI-поле в TLS ClientHello — то есть точное имя сайта.

Именно для решения этих двух проблем и были разработаны DoH и ECH.

SNI: имя сайта в открытом тексте

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

Это означает, что SNI виден всем, кто находится на пути между вами и сервером: провайдеру, оператору публичного Wi-Fi, любому сетевому оборудованию на маршруте. Раньше предлагался ESNI (Encrypted SNI) — упрощённая версия шифрования SNI, но она не получила широкого распространения из-за уязвимостей в дизайне. ECH — его переработанный и более проработанный преемник.

DoH — DNS-over-HTTPS: скрываем DNS-запросы

Обычный DNS работает через UDP/порт 53 в открытом виде. Провайдер видит каждый ваш запрос: google.com, youtube.com, любой сайт. DNS-over-HTTPS (RFC 8484) отправляет эти запросы как обычный HTTPS-трафик — зашифрованно и внешне неотличимо от веб-сёрфинга.

Как работает DoH

1
Браузер отправляет DNS-запрос не на системный резолвер, а на DoH-сервер по HTTPS
2
Запрос выглядит как обычный HTTPS-трафик — провайдер видит только IP DoH-сервера
3
DoH-сервер разрешает имя и возвращает IP зашифрованно
4
Провайдер не видит, какой домен вы запрашивали

Популярные DoH-серверы: Cloudflare (1.1.1.1), Google (8.8.8.8), NextDNS. Актуальные версии Chrome, Firefox, Edge и Safari поддерживают DoH и позволяют выбрать провайдера в настройках.

Важно
DoH защищает только DNS-запросы. Само TLS-соединение по-прежнему содержит SNI — имя сайта в открытом виде. DoH и ECH решают разные задачи.

ECH — Encrypted Client Hello: скрываем SNI

ECH (Encrypted Client Hello) — это расширение TLS 1.3, которое шифрует всё поле ClientHello, включая SNI. Вместо реального имени сайта провайдер видит только адрес CDN или фронтенд-сервера (например, Cloudflare).

Спецификация ECH описана в черновике IETF draft-ietf-tls-esni — формально она ещё не финализирована как RFC, но это не помешало массовому практическому внедрению: Cloudflare включил поддержку ECH по умолчанию для доменов под своей защитой ещё в 2023 году, и с тех пор база поддерживающих доменов только растёт.

Как работает ECH

1
Сервер публикует ECH-конфиг в DNS (запись HTTPS/SVCB)
2
Браузер получает публичный ключ через обычный или зашифрованный DNS-запрос
3
Браузер шифрует ClientHello с реальным SNI этим ключом
4
Провайдер видит только внешний SNI (например, адрес CDN)
5
Сервер расшифровывает реальный ClientHello своим приватным ключом

Ключевой момент: ECH требует, чтобы сайт его поддерживал и публиковал конфиг в DNS. Подробнее о том, как это настроено на стороне сервера — в документации Cloudflare по ECH.

GREASE ECH: зачем браузер шифрует Hello, даже если сервер не поддерживает

Пока спецификация ECH дорабатывается, у неё уже есть смежный механизм, который работает независимо от того, поддерживает конкретный сайт реальный ECH или нет — GREASE ECH.

Идея в следующем: даже если сервер не поддерживает ECH, браузер всё равно добавляет в ClientHello расширение ECH, заполненное случайными зашифрованными данными — «пустышку». По стандарту TLS 1.3 сервер обязан игнорировать незнакомые расширения, поэтому такое соединение работает как обычно.

Зачем это нужно
Проблема в том, что некоторое сетевое оборудование на маршруте (файрволы, устаревшие прокси) может обрывать соединение, если видит незнакомое TLS-расширение. Если бы браузеры включали настоящий ECH только для части сайтов, такое оборудование быстро научилось бы замечать именно эти случаи. GREASE ECH отправляется всегда и повсеместно — независимо от поддержки ECH конкретным сайтом, — поэтому сетевое оборудование вынуждено с самого начала корректно обрабатывать это расширение, а не блокировать его.

Иначе говоря, GREASE ECH — это подготовка почвы: он не скрывает SNI сам по себе (сервер без ECH всё равно получает и обрабатывает обычный, нешифрованный ClientHello), но приучает сеть к тому, что расширение ECH — это норма, а не аномалия, которую нужно блокировать.

ECH vs DoH: в чём разница

ТехнологияЧто скрываетЧто остаётся видимым
DoHDNS-запросы (имена доменов)SNI в TLS ClientHello, IP сервера
ECHSNI в TLS ClientHelloIP CDN/прокси, объём трафика
DoH + ECHDNS-запросы + SNIIP CDN/прокси, объём трафика
Шифрование всего трафикаВсё: DNS, SNI, IP, объёмIP сервера, к которому идёт зашифрованный канал

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

DoH

  • Chrome — поддерживает, включается в Настройки → Конфиденциальность → Безопасный DNS
  • Firefox — поддерживает, можно выбрать провайдера в настройках сети
  • Safari — поддерживает через конфигурационные профили (macOS, iOS)
  • Edge — поддерживает, настройки аналогичны Chrome

ECH

  • Chrome и Firefox — поддерживают ECH по умолчанию в актуальных версиях
  • Сайты за Cloudflare — ECH включён автоматически без дополнительной настройки
  • Safari — поддержка частичная и включается не во всех регионах и версиях
  • Самостоятельно хостируемые сайты — требуют отдельной настройки записи HTTPS/SVCB в DNS
  • Спецификация ECH формально ещё не финализирована как RFC — детали могут меняться
Поддержка зависит от сервера
ECH работает только там, где его включил владелец сайта или CDN перед ним. Это не настройка «включить везде» на стороне пользователя — без публикации ECH-конфига в DNS сервером браузеру просто нечем шифровать ClientHello, и соединение идёт с обычным, открытым SNI.

Ограничения и почему этого недостаточно

DoH и ECH — важные улучшения, но они не решают всех задач приватности:

  • IP-адрес сервера всё равно виден. По IP нередко можно определить сайт даже без DNS-запроса и без SNI — особенно если сайт не за общим CDN.
  • Объём и тайминг трафика остаются видимыми. Провайдер по-прежнему видит паттерн активности — сколько данных и когда передаётся.
  • ECH работает только там, где его включил сервер. Огромная часть сайтов в интернете ECH ещё не публикует, и SNI у них остаётся открытым.
  • DoH требует доверия DoH-провайдеру. Вместо интернет-провайдера DNS-запросы видит оператор резолвера — Cloudflare, Google и подобные.
  • Не все приложения используют DoH и ECH. Мобильные приложения, smart TV и IoT-устройства часто обращаются к сети напрямую, минуя настройки браузера.
  • Некоторое сетевое оборудование может прерывать нестандартные TLS-расширения. Устаревшие middlebox-ы иногда обрывают соединения, не понимая новые расширения — отсюда и нужен GREASE ECH.

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

Итог

DoH

Скрывает DNS-запросы. Включите в браузере — это просто и бесплатно.

ECH + GREASE ECH

Скрывает SNI там, где сервер поддерживает ECH. GREASE ECH готовит сеть к его массовому внедрению.

Шифрование всего трафика

Скрывает всё, независимо от поддержки на стороне конкретного сайта.

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

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

DoH (DNS-over-HTTPS) шифрует ваши DNS-запросы — какие сайты вы смотрите, больше не видит провайдер. ECH (Encrypted Client Hello) шифрует имя сайта в TLS-рукопожатии — поле SNI. Вместе они закрывают две главные утечки при обычном HTTPS.

Нет. DoH прячет DNS-запросы (шаг «узнать IP сайта»), ECH прячет SNI (шаг «сообщить серверу, за каким сайтом пришёл»). Это разные фазы соединения и разные технологии, которые работают вместе.

Да. DoH защищает только DNS. Сразу после DoH браузер отправляет TLS ClientHello с именем сайта в открытом виде — это SNI. Без ECH провайдер всё равно видит, на какой сайт вы идёте. Только ECH + DoH закрывают обе утечки.

Обычный ECH реально шифрует SNI — но только если сервер его поддерживает и опубликовал ключ в DNS. GREASE ECH браузер отправляет всегда, даже на сайты без поддержки ECH: это «пустышка» со случайными данными, которая приучает сетевое оборудование корректно обрабатывать расширение ECH и не обрывать соединение, встретив его впервые.

Да, но с оговорками. Chrome и Firefox поддерживают ECH в актуальных версиях, Safari — частично. На стороне сервера ECH должен включить владелец сайта: у доменов за Cloudflare он активен автоматически с 2023 года, для самостоятельного хостинга нужна отдельная настройка DNS-записей HTTPS/SVCB. Спецификация формально ещё не финализирована как RFC IETF.

Нет. Даже с ECH и DoH остаются видимыми: IP-адрес сервера (можно идентифицировать сайт по IP), объём и тайминг трафика (паттерн-анализ), а ECH вдобавок работает только там, где его включил конкретный сайт. Полностью скрыть активность можно только шифрованием всего соединения целиком.

AuraShield

Полное шифрование трафика

VLESS-Reality шифрует весь трафик — DNS, SNI, IP — и маскирует соединение под обычный HTTPS. Провайдер видит только обращение к нашему серверу. Два дня бесплатно.

Попробовать бесплатно →