HTTPS и метаданные: что реально шифруется, а что остаётся снаружи

Зелёный замок в адресной строке — самый известный визуальный сигнал безопасности и одновременно самый недопонятый. Многие воспринимают его как мантию невидимости. Но HTTPS — это не «всё закрыто», а очень конкретное обещание: закрыто содержимое прикладного уровня. Всё, что нужно сетевому оборудованию для доставки пакетов, по определению должно остаться видимым — иначе пакеты просто не доедут.

Полезно разделять соединение на слои и спрашивать про каждый: «что здесь видит посредник?». Тогда страх перед DPI и завышенные ожидания от шифрования одинаково сходят на нет, и остаётся понятная инженерная картина.

┌──────────────────────────┬──────────────────────────┐
│  Видно посреднику         │  Скрыто внутри TLS        │
├──────────────────────────┼──────────────────────────┤
│  IP клиента и сервера    │  путь URL после домена   │
│  порты (443, 853, 80)    │  query string и фрагмент │
│  IP-флаги, TTL           │  заголовки HTTP          │
│  размеры пакетов         │  cookies, токены         │
│  тайминги, jitter        │  тело страницы           │
│  SNI без ECH             │  ответы API              │
│  ALPN (h2/h3/http1)      │  содержимое форм         │
│  TLS-версия и cipher     │  сертификат (TLS 1.3)    │
└──────────────────────────┴──────────────────────────┘

Сетевая модель за пять секунд

Любое HTTPS-соединение проходит четыре уровня. На канальном сосед по Wi-Fi видит MAC-адреса. На сетевом любой маршрутизатор от вас до сервера видит IP-адреса. На транспортном ему доступны TCP-флаги или, в случае QUIC, размеры UDP-пакетов и Connection ID. И только на прикладном уровне начинается территория HTTPS: запросы, ответы, заголовки и тело.

HTTPS = TLS поверх транспорта плюс HTTP внутри TLS. Шифрование защищает только верхний этаж. Всё, что ниже, нужно самой сети для доставки и поэтому остаётся доступным наблюдателю.

Что видит сеть и зачем ей это

IP-адрес нужен маршрутизации: без него ни один маршрутизатор не знает, в какой next hop отдавать пакет. Порт нужен для выбора сервиса (443 — HTTPS, 853 — DoT, 5061 — SIP-TLS). Размеры и тайминги пакетов появляются естественным образом из поведения приложения и без специальных усилий не маскируются.

Конкретные ориентиры. ClientHello браузера — это около 500–700 байт. Полный TLS 1.3 handshake поверх TCP — обычно 6–9 пакетов и 4–8 КБ суммарно. После этого браузер начинает HTTP/2-поток. Запрос на тяжёлую страницу типа новостного сайта — это десятки HTTPS-сессий к разным CDN и сторонним API; всё это видно посреднику как набор соединений к разным IP в разное время. Стриминг-видео распознаётся по характерному паттерну: несколько секунд burst (буфер заполняется), потом долгая пауза, повтор. VoIP — это маленькие пакеты по 60–200 байт через равные 20 мс. Эти подписи не показывают содержимого, но позволяют грубо классифицировать тип трафика.

JA3, JA4 и fingerprinting клиента

Разные клиенты собирают ClientHello по-разному: порядок расширений, список cipher suites, поддерживаемые группы и сигнатуры. Эти параметры превращаются в хэш и образуют fingerprint — JA3 (старый формат) и JA4 (новый, более устойчивый). Один и тот же сайт, открытый из Chrome 130 и из cURL, выглядит в сети по-разному именно из-за этого отпечатка.

Fingerprint не раскрывает домена и тем более содержимого. Зато он отвечает на вопрос «какое приложение установило это соединение». Подробнее JA3/JA4 обсуждаются в статье про сигнатуры и метаданные.

Что HTTPS действительно закрывает

Внутри защищённого канала живут все вещи, ради которых вообще существует HTTPS: путь URL после имени хоста (/account/transactions), параметры запроса, заголовки (включая Authorization), cookies, тело форм, ответы API и весь HTML страницы. В TLS 1.3 туда же переехал и сертификат сервера — в 1.2 он летел открытым текстом, а сейчас зашифрован handshake-ключом.

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

DNS как утечка имени до TLS

Перед HTTPS браузер должен узнать IP-адрес. Классический DNS работает по UDP/53 открытым текстом — это значит, что любой посредник видит, какие домены вы открываете, ещё до того как стартует TLS. Поэтому SNI и DNS — две независимые «утечки имени», и для полной картины их закрывают вместе: DoH или DoT (или новый DoQ) шифруют сам DNS-запрос, а ECH прячет SNI внутри TLS.

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

Что должен сделать владелец сайта

Сторона сервера тоже влияет на то, насколько хорошо HTTPS защищает пользователя. Минимальный гигиенический набор:

• HSTS с max-age=31536000; includeSubDomains; preload. Браузер запоминает, что на этот домен ходят только по HTTPS, и игнорирует попытки понизить до HTTP.
• OCSP stapling. Сервер сам прикладывает свежий ответ от CA — браузер не ходит в OCSP отдельно и не утекает имя домена в ещё одну сторону.
• TLS 1.3 включён, 1.0/1.1 выключены. Современные браузеры и так не подключаются по 1.0/1.1, но сервер не должен их предлагать.
• Сертификат с CT-метками. Без них Chrome ругается на любой публичный сайт.
• Поддержка ECH на CDN и публикация HTTPS-записи в DNS — следующий шаг для тех, кому важна тишина SNI.

Почему это важно в 2026 году

Веб всё активнее переходит на TLS 1.3, ECH и HTTP/3. Каждое поколение протоколов прячет немного больше: сертификат, SNI, часть транспортных полей. Но IP-маршрутизация, задержки и поведение потоков никуда не денутся — они нужны самой сети. Поэтому будущее HTTPS — это не превращение интернета в чёрный ящик, а аккуратное сокращение того, что не нужно показывать наружу.

Итого

HTTPS — прочный фундамент приватности на прикладном уровне, но не плащ-невидимка для всего соединения. Правильный вопрос звучит не «видно или не видно», а «какой именно слой виден и зачем он нужен сети». Чем точнее вы видите границу, тем меньше иллюзий и тем надёжнее реальная защита.