Что такое SNI и почему HTTPS скрывает не всё

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

Разберём по шагам: как устанавливается HTTPS-соединение, зачем в нём вообще понадобилось незашифрованное имя домена, что из этого видит провайдер и сетевое оборудование, что меняет технология ECH и какую часть картины закрывает VPN, а какую не закрывает никто.

Что происходит до первого байта страницы

Прежде чем браузер получит хотя бы один байт HTML, устройство и сервер проходят два подготовительных этапа. Сначала устанавливается TCP-соединение: три коротких служебных пакета, которые подтверждают, что канал есть и обе стороны на связи. Шифрования здесь ещё нет, но и передавать пока нечего, кроме флагов и номеров.

Затем начинается рукопожатие TLS — протокола, который и превращает обычное соединение в HTTPS. Первым говорит клиент: он отправляет сообщение ClientHello. Оно уходит в сеть до того, как стороны договорились о ключах, а значит, физически не может быть зашифровано — расшифровывать его было бы нечем.

Что лежит внутри ClientHello

ClientHello — это не просто «привет», а довольно подробная анкета клиента:

Версии протокола — какие варианты TLS браузер готов использовать: сегодня это в первую очередь TLS 1.3, с оглядкой на TLS 1.2.
Список шифронаборов — какие алгоритмы шифрования и проверки целостности поддерживаются и в каком порядке предпочтения.
Случайное число и материал для ключей — в TLS 1.3 клиент сразу прикладывает свою часть будущего общего секрета, чтобы сократить число обменов.
Расширения — набор дополнительных полей. Среди них ALPN, сообщающий, какой протокол приложения нужен, и то самое server_name, то есть SNI.

SNI расшифровывается как Server Name Indication — «указание имени сервера». В нём открытым текстом написано, к какому домену обращается клиент. Сервер отвечает своим ServerHello, стороны вычисляют общие ключи, и всё дальнейшее идёт уже под шифрованием: сертификат сервера (в TLS 1.3 он тоже зашифрован), HTTP-заголовки, адреса конкретных страниц, содержимое ответов.

Стоит отметить, что за последние годы открытой информации в рукопожатии стало заметно меньше. В TLS 1.2 сертификат сервера передавался открытым текстом, и имя сайта можно было прочитать прямо из него, даже если SNI по какой-то причине отсутствовал. В TLS 1.3 сертификат ушёл под шифрование, и SNI остался, по сути, последним крупным полем, которое прямо называет адресата.

Ключевая деталь: HTTPS скрывает, что вы делаете на сайте, но не скрывает, на какой сайт вы пришли. Путь вида /orders/12345 не увидит никто, а вот домен в начале соединения — обычно да.

Зачем имя сайта передаётся открытым текстом

Это не недосмотр и не забытая дыра в протоколе. SNI появился как решение вполне конкретной инженерной задачи, без которого современный веб не собрался бы.

Один адрес — сотни сайтов

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

Проблема курицы и яйца

Для HTTPS сервер обязан предъявить сертификат, причём именно тот, что выписан на запрошенное имя. Если он отдаст сертификат чужого домена, браузер покажет ошибку и соединение оборвётся. Получается замкнутый круг: чтобы выбрать сертификат, нужно знать имя; чтобы прочитать имя из зашифрованного запроса, нужен уже установленный сеанс; чтобы установить сеанс, нужен сертификат.

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

Отдельно стоит сказать про HTTP/3 и QUIC. Там рукопожатие TLS упаковано внутрь QUIC-пакетов, и формально начальные пакеты зашифрованы — но ключи для них выводятся из значений, которые видны в открытом заголовке каждому. Смысл такой защиты в целостности, а не в приватности: наблюдатель по-прежнему может извлечь имя сервера. Переход на HTTP/3 сам по себе картину не меняет.

Что видит провайдер и сетевое оборудование

Соберём вместе: что именно наблюдатель на пути трафика — интернет-провайдер, владелец Wi-Fi-сети в кафе, корпоративный шлюз, оборудование фильтрации на магистрали — может извлечь из HTTPS-соединения без всякой расшифровки.

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

Что при этом остаётся скрытым

Скрыто содержимое: адреса конкретных страниц, параметры запросов, тексты, логины и пароли, переписка, файлы. Наблюдатель знает, что вы соединялись с некоторым сайтом в 21:14 и обменялись с ним четырьмя мегабайтами, но не знает, что именно вы там читали, писали или скачивали. Это существенная защита — и одновременно куда меньшая, чем принято думать.

Отдельный случай — корпоративные и учебные сети, где на устройство заранее установлен собственный корневой сертификат организации. Тогда шлюз может расшифровывать трафик полностью и видеть уже не только домены, но и содержимое. Это не изъян HTTPS, а сознательно настроенная схема с доверием к сертификату, который вы (или администратор вашего устройства) добавили в систему. На личном устройстве без таких сертификатов подобная схема не работает.

Почему одного списка доменов достаточно

Есть распространённый аргумент: «ну и что, что видны домены, там же нет ничего личного». На практике список доменов с временными метками — это подробный дневник.

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

Метаданные — это не «неполные данные». Часто это самая концентрированная их часть: чтобы восстановить картину дня, достаточно знать адреса, время и объёмы, не читая ни одного сообщения.

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

ECH: шифрование того самого поля

Технология, которая закрывает эту брешь, называется Encrypted Client Hello, сокращённо ECH. Логика такая: клиент формирует «внутренний» ClientHello с настоящим именем сайта, шифрует его открытым ключом инфраструктуры, на которой сайт размещён, и вкладывает внутрь «внешнего» ClientHello с нейтральным общим именем. Наблюдатель видит только оболочку — обращение к некоторому общему имени провайдера инфраструктуры, — а настоящий адресат остаётся скрытым.

Открытый ключ клиент берёт из DNS: у домена публикуется специальная запись с параметрами ECH. Отсюда первое условие — DNS-запрос сам должен быть зашифрован через DNS over HTTPS или DNS over TLS. Иначе имя домена уйдёт открытым текстом на шаг раньше, и шифровать ClientHello будет уже бессмысленно. Как устроен этот этап, мы разбирали в материале о том, что такое DNS простыми словами.

У ECH был предшественник — ESNI, где шифровалось только одно поле с именем сервера. От него отказались: скрыть имя, оставив остальную анкету клиента открытой, оказалось недостаточно — по составу расширений и параметров соединение всё равно неплохо опознавалось. Нынешний подход шифрует ClientHello целиком, поэтому и называется зашифрованным ClientHello, а не зашифрованным SNI.

Почему ECH пока работает не везде

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

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

Что меняет VPN

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

Что при этом остаётся видно провайдеру: факт соединения с одним конкретным IP-адресом, протокол и порт, время начала и конца сессии, объём переданных данных. Список посещённых доменов из этого набора не восстанавливается — он просто не выходит наружу в открытом виде. Подробнее эта картина разобрана в отдельном материале о том, что видит провайдер, когда включён VPN.

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

Чего VPN здесь не делает

Честный ответ на вопрос «а теперь никто ничего не видит?» звучит так: видит, просто другой. VPN не уничтожает метаданные, он перемещает точку, в которой они собираются.

Что видит сам VPN-сервис

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

Что VPN не скрывает в принципе

Вас перед самим сайтом — если вы вошли в аккаунт, сайт знает, кто вы, с какого бы адреса ни пришло соединение.
Отпечаток браузера и cookie — трекеры опознают устройство по набору характеристик и сохранённым идентификаторам, а не по IP.
Активность внутри приложений, которые сами отправляют данные о вас на свои серверы.
Последствия ошибок настройки — при некорректной конфигурации DNS-запросы могут уходить мимо туннеля, и список доменов снова становится виден провайдеру.

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

Частые вопросы

Видит ли провайдер, какие страницы я открываю на сайте?

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

Если включить шифрованный DNS, имя сайта перестанет быть видимым?

Не полностью. DNS over HTTPS закрывает этап преобразования имени в адрес, но само имя всё равно уйдёт в SNI при установке TLS-соединения, если сайт и браузер не используют ECH.

Можно ли считать проблему решённой после внедрения ECH?

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

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