Какие части HTTP-запроса (хедеры, тело) шифруются в HTTPS
Что проверяют
Понимаете ли вы, на каком уровне работает TLS и что остаётся видно наблюдателю в сети. Ловушка в том, что многие уверены, будто URL не шифруется. Следом обычно спрашивают, где тогда утекает адрес и почему токен в query-параметре всё равно плохая идея.
Как отвечать
HTTP передаётся внутри TLS целиком, сам HTTP о шифровании не знает. Поэтому в туннеле оказываются:
- стартовая строка: метод, путь и query-строка, то есть
/orders?token=...снаружи не виден; - заголовки:
Host,Cookie,Authorization,User-Agent; - тело: JSON, формы, файлы.
Открытым остаётся то, что нужно для доставки пакетов и установки соединения:
- IP-адреса и порты: кто с кем говорит;
- имя хоста: утекает через DNS-запрос (если нет DoH или DoT) и через поле SNI в
ClientHello. Скрыть SNI может ECH, но его должны поддерживать и браузер, и сервер; - размеры и тайминги: по ним иногда можно угадать, какая страница открыта.
Для фронтендера важен второй слой: где URL видят уже после расшифровки. Это история браузера, логи сервера и прокси, системы аналитики, заголовок Referer при ослабленной Referrer-Policy. Поэтому токены и персональные данные передают в заголовке или теле, а не в query. Вкладка Network в DevTools показывает запросы до шифрования, так что то, что вы там всё видите, о защите ничего не говорит.
Где спотыкаются
Говорят, что URL открыт целиком. На самом деле снаружи виден только домен, а путь и параметры зашифрованы.
Считают, что раз HTTPS, то query-параметры безопасны. От перехвата в сети да, от логов, истории и аналитики нет.
Забывают про метаданные: IP, SNI и объём трафика позволяют понять, на какой сайт ходит пользователь, даже без расшифровки содержимого.