Что видит провайдер, когда вы открываете сайт по HTTPS

MAATRIX

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

Что видит провайдер в HTTPS-трафике

HTTPS шифрует полезную нагрузку — тело запроса, заголовки, куки, содержимое страницы. Но пакет всё равно должен доставиться от вас до сервера, а значит, часть информации остаётся открытой на уровне IP и TCP/TLS-заголовков, через которые проходит любой узел на маршруте, включая провайдера:

• IP-адрес назначения. Провайдер видит, к какому серверу вы подключились. Если на этом IP висит один сайт (выделенный сервер, отдельный VPS) — это прямое указание, куда вы ходили. Если это общий хостинг или CDN вроде Cloudflare, на одном IP могут сидеть тысячи разных доменов — тогда IP сам по себе не говорит, какой именно сайт вы открыли.
• Порт назначения. 443 для HTTPS, 80 для HTTP, 22 для SSH и так далее — по номеру порта видно тип сервиса, но не его содержимое.
• Объём трафика. Сколько байт ушло от вас и сколько пришло в ответ. По объёму и характеру передачи (много мелких запросов подряд vs один крупный поток) можно с некоторой вероятностью отличить, например, просмотр видео от чтения текстовой страницы — но это эвристика, а не точное знание.
• Тайминги. Когда началось соединение, сколько оно длилось, с какой периодичностью появляются новые пакеты. По паттерну таймингов провайдер (или любой, кто анализирует его логи) может сопоставлять сессии между собой — это одна из техник корреляции трафика.
• SNI — имя домена в открытом виде. Это самый недооценённый пункт, разберём его отдельно ниже.

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

SNI: незашифрованное имя сайта в ClientHello

TLS-соединение начинается с рукопожатия (handshake) — если хотите разобрать его по шагам целиком, есть отдельная статья про TLS-рукопожатие и что происходит до первого байта. Ключевой для этой темы момент: первое сообщение клиента — ClientHello — отправляется до того, как стороны договорились об общем шифре и начали шифровать данные. Именно в ClientHello браузер передаёт поле SNI (Server Name Indication) — имя домена, к которому он хочет подключиться.

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

Проверить своими глазами, что SNI действительно передаётся в открытом виде, можно через openssl s_client:

openssl s_client -connect example.com:443 -servername example.com -tlsextdebug 2>&1 | head -30

Или ещё нагляднее — захватить пакет и посмотреть его в Wireshark (см. раздел про Wireshark ниже): в первом же TLS-пакете от клиента, до Server Hello, поле Extension: server_name читается открытым текстом.

Практический вывод: провайдер, увидевший ваш пакет с ClientHello, узнаёт домен назначения (example.com), даже если после этого весь остальной трафик зашифрован и содержимое страницы ему недоступно. Это касается не только вашего провайдера — но и любого узла на маршруте пакета до сервера, если трафик не защищён туннелем.

ECH (Encrypted Client Hello) — развивающийся стандарт, который шифрует и SNI тоже, пряча его внутри дополнительного слоя шифрования с отдельным ключом, публикуемым через DNS (HTTPS resource record). На конец августа 2026 года поддержка ECH расширяется в актуальных версиях Chrome и Firefox, но остаётся не универсальной: она зависит одновременно от браузера, от того, поддерживает ли ECH сервер/CDN на другой стороне, и от того, доступен ли клиенту защищённый DNS для получения ключа. Пока эта цепочка не выполняется полностью и повсеместно, SNI по-прежнему остаётся видимым по умолчанию для огромной доли соединений — считайте его видимым, пока не проверили обратное для конкретного сайта и браузера.

DNS-запрос до соединения: ещё одна утечка, отдельная от TLS

Прежде чем браузер вообще отправит первый TCP-пакет к серверу, ему нужно превратить домен example.com в IP-адрес — то есть сделать DNS-запрос. Если этот запрос идёт обычным способом (классический DNS по UDP/TCP на порт 53, без шифрования), он тоже виден провайдеру — причём это отдельный источник информации от SNI, не связанный с TLS напрядую. Провайдер видит DNS-запрос сам по себе, даже если бы у вас каким-то образом получилось скрыть SNI.

Более того, если резолвер, который вы используете — это DNS-сервер самого провайдера (что настроено по умолчанию почти у всех, кто не менял DNS вручную), провайдер получает это же имя домена ещё и напрямую как оператор резолвера, а не только как транзитный узел на пути к TLS-серверу.

Здесь появляются два независимых способа спрятать это конкретное имя:

• DoH (DNS over HTTPS) — DNS-запрос заворачивается в обычный HTTPS-запрос к серверу-резолверу (Cloudflare, Google, Quad9 и др.), внешне неотличимый от обращения к любому HTTPS-сайту. Подробнее о механике и ограничениях — в статье про DNS over HTTPS и его влияние на доступ к сервисам.
• DoT (DNS over TLS) — то же самое, но через отдельный TLS-туннель на порт 853, различимый по номеру порта (то есть провайдер видит факт использования DoT, но не содержимое запроса).

Важная оговорка: даже если вы включили DoH или DoT, это защищает только сам DNS-запрос. Если после получения IP браузер всё равно отправляет ClientHello с открытым SNI на этот IP — провайдер узнает домен назначения из SNI, даже не имея доступа к вашему DNS-трафику. Поэтому DoH/DoT и защита SNI — это две разные, не взаимозаменяемые задачи. Проверить, есть ли у вас утечка DNS-запросов мимо защищённого канала, можно способом, описанным в статье про проверку и закрытие DNS leak при использовании VPN.

Чего провайдер НЕ видит

При всей открытости метаданных TLS честно закрывает главное — содержимое:

• Путь и параметры URL. example.com виден через SNI, но example.com/user/12345/settings?token=abc — нет. Всё, что идёт после домена (путь, query-параметры, фрагмент), передаётся уже внутри зашифрованного канала после завершения handshake.
• Заголовки HTTP-запроса и ответа, включая cookies, авторизационные токены, User-Agent (в смысле передачи по сети — сам факт использования конкретного браузера теоретически можно предположить по другим признакам, но не прочитать из заголовка).
• Тело запроса и ответа — формы, которые вы отправляете, файлы, которые загружаете, HTML/JSON/картинки, которые получаете.
• Содержимое переписки, платежных данных, паролей — всё, что передаётся после установления TLS-сессии, защищено симметричным шифром, согласованным в ходе handshake, и без приватного ключа сервера (или компрометации самого клиента/сервера) нечитаемо.

Итог этого раздела простой: провайдер знает факт «кто-то из вашей сети зашёл на example.com в 14:32 и передал 2.3 МБ трафика за 40 секунд», но не знает, что именно вы там делали — читали статью, оформляли заказ или писали в чат.

Что даёт VPN в этом контексте, а что не даёт

Здесь стоит быть честными, потому что маркетинг VPN-сервисов регулярно обещает больше, чем технология может выполнить.

Что VPN действительно меняет:

• Ваш провайдер вместо реального IP назначения и SNI сайта видит только IP VPN-сервера и один непрерывный зашифрованный туннель (обычно WireGuard или OpenVPN). Он не видит ни SNI сайта, ни объём трафика на уровне отдельных сайтов — только суммарный трафик к VPN-серверу.
• DNS-запросы, если клиент VPN настроен правильно, уходят через туннель к DNS-серверу самого VPN-провайдера или к указанному вами резолверу, а не к резолверу вашего интернет-провайдера.

Что VPN не меняет:

• Провайдер VPN-сервера теперь видит то же самое, что раньше видел ваш интернет-провайдер — вы просто перенесли точку наблюдения, а не убрали её. Если это ваш собственный сервер, вы контролируете эту точку сами; если это чужой VPN-сервис — вопрос доверия просто сместился на него, и здесь честная позиция обычно расписана в статье про то, что лучше для бизнеса — коммерческий VPN или свой сервер.
• VPN не меняет содержимое HTTPS-сессии — TLS и так шифровал тело, заголовки и куки без всякого VPN. VPN добавляет ещё один слой шифрования поверх, но не открывает и не закрывает то, что TLS уже скрывал.
• Корреляция по таймингам и объёму никуда не девается полностью — она просто усложняется, потому что весь ваш трафик смешивается с трафиком других пользователей того же VPN-сервера (если сервер общий) или маскируется под один туннель. На выделенном личном VPS такого «смешения с толпой» нет — тайминг-паттерны вашего собственного трафика всё ещё различимы тем, кто видит трафик на входе VPN-сервера.
• Сайт на другом конце по-прежнему видит вас как посетителя — через куки, fingerprinting браузера, авторизацию — просто с другого IP-адреса. VPN скрывает маршрут от вас до сайта на уровне сети, но не отменяет идентификацию на уровне приложения.

Вывод: VPN — это не «невидимость», а смена точки, откуда видна метаданная информация о вашем трафике, плюс дополнительное шифрование транспортного уровня. Это осмысленный инструмент, если вы понимаете, кому в итоге переносите доверие.

Практика: смотрим собственный трафик в Wireshark

Проще всего перестать гадать и увидеть эти утечки метаданных своими глазами. Понадобится Wireshark (бесплатный, есть под Windows/macOS/Linux) и обычный браузер.

Шаг 1. Запустите захват на нужном интерфейсе

Выберите активный сетевой интерфейс (Wi-Fi или Ethernet) в списке Wireshark и нажмите старт захвата. Если работаете через терминал на Linux/macOS, эквивалент — tcpdump, разбор его вывода подробно описан в статье про анализ VPN-трафика через tcpdump.

Шаг 2. Откройте в браузере новый сайт, который раньше не посещали в этой сессии (чтобы не сработал DNS-кэш и кэш TLS-сессии — иначе часть пакетов не появится).

Шаг 3. Найдите DNS-запрос

В строке фильтра Wireshark введите:

dns

Вы увидите запрос типа A или AAAA к домену открытым текстом — и в нём же имя домена, которое вы вводили в адресную строку. Если у вас настроен DoH, этого пакета в списке dns не будет — вместо него появится обычный HTTPS-трафик к IP резолвера (например, 1.1.1.1 или 8.8.8.8), и содержимое запроса будет зашифровано так же, как обычный сайт.

Шаг 4. Найдите ClientHello и поле SNI

Фильтр:

tls.handshake.type == 1

Это выведет только пакеты ClientHello. Откройте такой пакет, разверните дерево Transport Layer Security → Handshake Protocol → Extension: server_name → Server Name Indication extension → Server Name. Значение будет читаться открытым текстом — это и есть тот самый домен, который видит провайдер, даже когда весь остальной трафик уже зашифрован.

Шаг 5. Сравните с зашифрованной частью

Отфильтруйте по tls.record.content_type == 23 (Application Data) — это уже зашифрованные прикладные данные, идущие после handshake. Раскройте пакет — в нём не будет читаемого текста, только байты шифротекста. Это наглядная граница: до этого фильтра — открытые метаданные, после — зашифрованное содержимое.

Если хотите этот же эксперимент повторить с активным VPN-туннелем, чтобы увидеть разницу, общий разбор перехваченного трафика VPN-соединения — в статье Wireshark: анализ VPN-соединения. При активном туннеле фильтры dns и tls.handshake.type == 1 на внешнем интерфейсе не покажут ничего, кроме трафика к самому VPN-серверу — весь внутренний DNS и TLS-handshake к сайтам окажется внутри зашифрованного тоннеля и снаружи будет виден только как непрозрачный поток UDP/TCP пакетов к одному IP.

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