Если используешь HTTPS, URL зашифрован или нет

Уровни шифрования в HTTPS: URL, заголовки и тело

Нет, при использовании HTTPS (Hypertext Transfer Protocol Secure) URL (Uniform Resource Locator) не шифруется целиком. Это распространённое заблуждение. Давайте разберём, что именно защищает HTTPS и какие части запроса остаются видимыми.

Что шифрует HTTPS?

HTTPS работает поверх TLS (Transport Layer Security) или его предшественника SSL. После успешного рукопожатия TLS (TLS handshake) устанавливается зашифрованный канал. В этом канале шифруется:

• Тело HTTP-запроса (HTTP Body): Все данные, которые вы отправляете (логины, пароли, сообщения, данные форм) или получаете (содержимое страниц, файлы).
• Заголовки HTTP (HTTP Headers): Такие как Authorization, Cookie, Referer, User-Agent и другие. Они скрыты от посторонних глаз.

Однако, часть информации необходима для самой маршрутизации данных в интернете и остаётся открытой.

Что НЕ шифруется и почему?

Для установления соединения и доставки пакетов до нужного сервера сетевой инфраструктуре (маршрутизаторам, DNS-серверам) требуется определённая метаинформация:

1. Доменное имя (Hostname) из URL:

    *   Оно извлекается и передаётся в открытом виде в расширении **SNI (Server Name Indication)** во время рукопожатия TLS. Это нужно, чтобы сервер, который может обслуживать множество сайтов на одном IP-адресе (виртуальный хостинг), понял, какой SSL-сертификат и какое веб-приложение использовать.
    *   Пример: В URL `https://example.com/secure/very-secret-page?id=123` часть `example.com` будет видна в SNI.

1. IP-адрес сервера и клиента:

    *   IP-заголовки сетевого уровня (IP-адреса отправителя и получателя) не являются частью HTTPS/TLS и необходимы для маршрутизации пакетов через интернет.

1. Порт назначения (обычно 443 для HTTPS):

    *   Также виден для правильной доставки трафика на нужный сервис на сервере.

1. Полный путь и параметры запроса (Query String):

    *   **Это ключевой момент.** Путь, который идёт после доменного имени, и параметры (то, что после `?`) **шифруются в рамках HTTP-запроса внутри TLS-туннеля**.
    *   В нашем примере `/secure/very-secret-page?id=123` будет зашифровано. Ни промежуточный провайдер, ни кто-либо, прослушивающий трафик, не увидят эту часть URL.
    *   Однако, как мы выяснили выше, доменное имя (`example.com`) из URL — видно.

Наглядный пример

Рассмотрим запрос: https://api.bank.com/v1/transactions?user_id=789&filter=year2024

Что видно стороннему наблюдателю (провайдеру, в публичной Wi-Fi сети)?

• Видно (открыто):

    *   IP-адрес сервера, соответствующего `api.bank.com`.
    *   Факт обращения к `api.bank.com` через SNI.
    *   Порт 443.

• Не видно (зашифровано TLS):

    *   Путь: `/v1/transactions`
    *   Параметры запроса: `?user_id=789&filter=year2024`
    *   Заголовки (например, `Authorization: Bearer <ваш_токен>`).
    *   Тело запроса/ответа (например, сумма перевода, детали транзакций).

# Пример того, что может увидеть злоумышленник при пассивном прослушивании
# (упрощённо, с помощью таких инструментов как tcpdump или Wireshark)
# Он увидит примерно следующее:

Client -> Server [SYN] to IP: 93.184.216.34 (IP для example.com)
TLS ClientHello Extension: server_name: api.bank.com # SNI - ДОМЕН ВИДЕН!
... далее идёт зашифрованный трафик, который выглядит как бессмысленный набор байтов.

Исключение и будущие изменения

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

• Encrypted Client Hello (ECH) / Encrypted SNI (ESNI): Являются частью новейших версий TLS (1.3 и далее). Они позволяют зашифровать даже расширение SNI, сделав доменное имя невидимым для посторонних. Поддержка пока не является повсеместной, но активно развивается.

Вывод для DevOps-инженера

Понимание этого нюанса критически важно для:

• Безопасности: Осознания, что конфиденциальные данные никогда не должны передаваться в самом URL (даже с HTTPS), если есть малейшая вероятность, что URL может попасть в логи веб-сервера, прокси или браузера.
• Аналитики и мониторинга: Знания, что сетевые провайдеры или межсетевые экраны могут логировать доменные имена, но не внутренние пути запросов.
• Проектирования архитектуры: При выборе и настройке WAF (Web Application Firewall), прокси-серверов (например, Nginx, Apache) или систем контроля доступа необходимо учитывать, что на уровне TLS они видят только SNI, а для анализа полного URL им необходимо выполнить терминирование TLS (TLS termination), то есть расшифровать трафик на себе.

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