TLS Handshake

TLS Handshake через прокси-сервис устанавливает защищённое соединение между клиентом и целевым сервером, при этом прокси может выступать как прозрачным туннелем, так и активным посредником, перехватывающим и перешифровывающим трафик.

Основы TLS Handshake

TLS (Transport Layer Security) Handshake — это протокол, который устанавливает зашифрованное соединение между двумя сторонами (клиентом и сервером). Он включает обмен сообщениями для согласования алгоритмов шифрования, обмена ключами и аутентификации сервера (опционально клиента).

Основные этапы стандартного TLS Handshake:
1. ClientHello: Клиент отправляет серверу список поддерживаемых версий TLS, наборов шифров (cipher suites), методов сжатия, а также случайное число и расширения (например, SNI).
2. ServerHello: Сервер выбирает оптимальную версию TLS, набор шифров и метод сжатия из предложенных клиентом, генерирует своё случайное число и отправляет их клиенту.
3. Certificate: Сервер отправляет свой цифровой сертификат, содержащий публичный ключ и информацию о владельце. Клиент проверяет сертификат на подлинность и доверие.
4. ServerKeyExchange (опционально): Если выбранный набор шифров требует обмена ключами Диффи-Хеллмана (DHE/ECDHE), сервер отправляет параметры для этого обмена.
5. ServerHelloDone: Сервер сигнализирует об окончании своих сообщений на этапе Hello.
6. ClientKeyExchange: Клиент генерирует предварительный секрет (premaster secret), шифрует его публичным ключом сервера (из сертификата) или использует параметры DHE/ECDHE, и отправляет серверу.
7. ChangeCipherSpec (Клиент): Клиент уведомляет сервер, что все последующие сообщения будут зашифрованы с использованием согласованных ключей.
8. Finished (Клиент): Клиент отправляет зашифрованное сообщение, содержащее хэш всех предыдущих сообщений Handshake, для проверки целостности.
9. ChangeCipherSpec (Сервер): Сервер делает то же самое.
10. Finished (Сервер): Сервер отправляет свой зашифрованный хэш.

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

Роль Прокси в TLS Handshake

Прокси-сервисы могут по-разному взаимодействовать с TLS Handshake в зависимости от их типа и конфигурации.

Прозрачный прокси (Transparent Proxy)

Прозрачный прокси перехватывает сетевой трафик на уровне IP без необходимости настройки клиента. Для TLS-трафика он обычно не вмешивается в процесс Handshake. Клиент устанавливает TCP-соединение с целевым сервером, а прозрачный прокси просто маршрутизирует пакеты. TLS Handshake происходит напрямую между клиентом и сервером, и прокси не видит незашифрованного содержимого. Он может видеть только IP-адреса, порты и SNI (Server Name Indication) в ClientHello.

HTTP-прокси с методом CONNECT

Это наиболее распространённый сценарий для HTTPS через прокси. Клиент запрашивает у прокси установку TCP-туннеля до целевого сервера. Прокси действует как ретранслятор байтов, не пытаясь дешифровать трафик.

Процесс:
1. Клиент устанавливает TCP-соединение с прокси-сервером.
2. Клиент отправляет HTTP CONNECT запрос прокси-серверу, указывая хост и порт целевого HTTPS-сервера.
http CONNECT example.com:443 HTTP/1.1 Host: example.com:443 Proxy-Connection: Keep-Alive
3. Прокси-сервер устанавливает TCP-соединение с example.com на порт 443.
4. Если соединение успешно, прокси отвечает клиенту:
http HTTP/1.1 200 Connection established
5. После этого прокси просто передаёт все последующие байты между клиентом и example.com без изменений.
6. Клиент и example.com выполняют полный TLS Handshake сквозь этот туннель. Прокси не участвует в обмене ключами и не может дешифровать трафик.

В этом сценарии прокси видит только CONNECT запрос и зашифрованный TLS-трафик. Он не имеет доступа к HTTP-заголовкам или содержимому после установления TLS-туннеля.

SSL/TLS-перехватывающий прокси (Man-in-the-Middle, MITM Proxy)

MITM-прокси активно вмешивается в TLS Handshake с целью инспекции, фильтрации или модификации зашифрованного трафика. Для этого прокси устанавливает два отдельных TLS-соединения: одно с клиентом, другое с целевым сервером.

Процесс:
1. Клиент -> Прокси (TLS Handshake 1):
* Клиент устанавливает TCP-соединение с прокси.
* Клиент отправляет CONNECT запрос (если это явный прокси) или трафик перенаправляется (если прозрачный прокси).
* Клиент инициирует TLS Handshake (ClientHello).
* Прокси перехватывает ClientHello. Оно определяет целевой домен (используя SNI из ClientHello).
* Прокси генерирует новый SSL-сертификат для целевого домена (например, example.com), который подписан его собственным корневым центром сертификации (CA).
* Прокси отправляет этот сгенерированный сертификат клиенту в ServerHello/Certificate сообщении.
* Клиент продолжает Handshake с прокси, используя этот сгенерированный сертификат.
* Для успешной работы клиент должен доверять корневому CA прокси (обычно это требует установки сертификата CA прокси в хранилище доверенных корневых CA клиента).
2. Прокси -> Целевой сервер (TLS Handshake 2):
* После завершения Handshake с клиентом, прокси устанавливает TCP-соединение с целевым сервером (example.com).
* Прокси действует как обычный TLS-клиент, инициируя свой собственный TLS Handshake с example.com.
* Целевой сервер отправляет свой оригинальный сертификат прокси.
* Прокси проверяет подлинность оригинального сертификата целевого сервера.
* Прокси завершает Handshake с целевым сервером.
3. Дешифрование и перешифрование:
* Теперь прокси имеет два установленных TLS-соединения. Оно дешифрует трафик, поступающий от клиента, инспектирует его, а затем перешифровывает и отправляет целевому серверу.
* Аналогично, трафик от целевого сервера дешифруется, инспектируется и перешифровывается для клиента.

MITM-прокси используются для целей безопасности (DLP, антивирусная проверка, фильтрация контента), мониторинга или кэширования. Несанкционированное использование MITM-прокси является серьёзным нарушением безопасности.

Сравнение CONNECT-метода и MITM-перехвата

Характеристика	HTTP-прокси (CONNECT)	SSL/TLS-перехватывающий прокси (MITM)
Цель	Туннелирование TCP-соединения	Инспекция и модификация зашифрованного трафика
Количество TLS Handshake	Один (Клиент <-> Целевой сервер)	Два (Клиент <-> Прокси, Прокси <-> Сервер)
Доступ к содержимому	Нет (только метаданные CONNECT запроса)	Полный доступ к дешифрованному трафику
Модификация трафика	Нет	Да
Требование к клиенту	Поддержка CONNECT метода	Установка корневого CA прокси
Сертификат, видимый клиенту	Оригинальный сертификат целевого сервера	Сгенерированный прокси-сертификат, подписанный его CA
Применение	Общий доступ в Интернет, обход фаерволов	Корпоративная безопасность, DPI, мониторинг

Расширения TLS и их влияние на прокси

SNI (Server Name Indication)

SNI — это расширение TLS, которое позволяет клиенту указать имя хоста, к которому он пытается подключиться, на ранней стадии TLS Handshake (в ClientHello). Это критично для серверов, которые обслуживают несколько доменов по одному IP-адресу.

• HTTP-прокси (CONNECT): Прокси использует информацию из CONNECT запроса (Host: example.com:443) для установления соединения с целевым сервером. SNI в ClientHello, проходящем через туннель, используется целевым сервером для выбора правильного сертификата. Прокси не изменяет SNI.
• MITM-прокси: Прокси извлекает SNI из ClientHello клиента. Эта информация используется для:
  • Определения целевого сервера для установки второго TLS-соединения.
  • Генерации сертификата для клиента, который соответствует запрошенному имени хоста.

ALPN (Application-Layer Protocol Negotiation)

ALPN — это расширение TLS, которое позволяет клиенту и серверу согласовать протокол прикладного уровня (например, HTTP/1.1, HTTP/2) в рамках TLS Handshake.

• HTTP-прокси (CONNECT): ALPN-согласование происходит между клиентом и целевым сервером. Прокси не вмешивается.
• MITM-прокси: Прокси может влиять на ALPN.
  • В Handshake Клиент <-> Прокси: Прокси может предложить клиенту свои поддерживаемые протоколы.
  • В Handshake Прокси <-> Целевой сервер: Прокси может запросить у целевого сервера протокол, который оно само поддерживает или хочет использовать.
  • Это позволяет прокси, например, преобразовывать HTTP/2-трафик от клиента в HTTP/1.1 для целевого сервера, если прокси или целевой сервер не поддерживают HTTP/2.

Особенности HTTP/2 через прокси

HTTP/2 может быть установлен через прокси двумя основными способами:

1. CONNECT метод:
   • Клиент отправляет CONNECT host:443 HTTP/1.1 прокси.
   • После получения 200 Connection established, клиент инициирует TLS Handshake.
   • В ClientHello, клиент использует ALPN для указания поддержки h2 (HTTP/2) и http/1.1.
   • Если целевой сервер поддерживает h2, он выбирает его через ALPN.
   • Весь HTTP/2 трафик затем передаётся через TLS-туннель.
2. Прозрачный прокси: Если прокси прозрачен и не перехватывает TLS, HTTP/2 устанавливается напрямую между клиентом и сервером через TLS Handshake с ALPN.

В случае MITM-прокси, прокси может выступать в качестве шлюза, конвертируя HTTP/2 от клиента в HTTP/1.1 для целевого сервера, если это необходимо для инспекции или по другим причинам. Это требует, чтобы прокси понимал и мог обрабатывать оба протокола.

Понимание механизмов TLS Handshake через прокси является фундаментальным для отладки сетевых проблем, обеспечения безопасности и эффективного управления прокси-сервисами.