HTTPS CONNECT

Метод HTTPS CONNECT позволяет клиенту установить сквозное TCP-соединение через HTTP-прокси-сервер до целевого узла, инкапсулируя зашифрованный трафик (например, HTTPS) внутри туннеля без возможности его дешифровки прокси.

Обзор проблемы и решения

Традиционные HTTP-прокси (RFC 7230, RFC 7231) предназначены для обработки HTTP-трафика, где клиент отправляет прокси-серверу полный URL (GET http://example.com/page.html). Прокси-сервер сам устанавливает соединение с целевым сервером, получает контент и передает его клиенту. Однако такой подход неприменим для HTTPS, поскольку трафик между клиентом и целевым сервером зашифрован с использованием TLS. Прокси не может "видеть" URL внутри зашифрованного потока, а попытка его расшифровать приведет к нарушению безопасности (MITM-атака, если клиент не доверяет сертификату прокси).

Для решения этой проблемы был введен метод CONNECT. Он позволяет клиенту запросить у прокси-сервера установку прямого TCP-соединения с указанным хостом и портом. После успешного установления соединения прокси-сервер просто передает байты между клиентом и целевым сервером, не вмешиваясь в содержимое трафика. Это создает "туннель" для любого TCP-протокола, включая HTTPS.

Метод HTTP/1.1 CONNECT

Когда клиент хочет установить зашифрованное соединение через прокси, он использует метод CONNECT.

Запрос клиента

Клиент отправляет HTTP-запрос прокси-серверу, используя метод CONNECT:

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.88 Safari/537.36
Proxy-Connection: Keep-Alive

• CONNECT www.example.com:443 HTTP/1.1: Это строка запроса. www.example.com — целевой хост, 443 — целевой порт (стандартный для HTTPS).
• Host: Заголовок Host указывает на целевой хост, с которым прокси должен установить соединение.
• Proxy-Connection: Заголовок Proxy-Connection (нестандартный, но часто используемый) может использоваться для управления поведением соединения между клиентом и прокси.

Ответ прокси-сервера

При получении запроса CONNECT прокси-сервер выполняет следующие действия:
1. Парсит запрос, извлекая целевой хост и порт.
2. Устанавливает новое TCP-соединение с www.example.com на порт 443.
3. Если соединение с целевым сервером успешно установлено, прокси отправляет клиенту ответ 200 Connection established.

HTTP/1.1 200 Connection established
Proxy-Agent: MyProxy/1.0

• HTTP/1.1 200 Connection established: Этот ответ сигнализирует клиенту, что прокси успешно установил соединение с целевым сервером и готов начать туннелирование.

Если прокси не может установить соединение (например, из-за сетевых проблем, правил фаервола или отказа целевого сервера), он возвращает соответствующий HTTP-статус ошибки (например, 503 Service Unavailable, 403 Forbidden).

Туннелирование данных

После получения ответа 200 Connection established клиент и прокси-сервер переходят в режим туннелирования. Прокси-сервер перестает парсить HTTP-запросы и ответы. Все последующие байты, полученные от клиента, передаются напрямую целевому серверу, и все байты, полученные от целевого сервера, передаются напрямую клиенту. Это сквозное двунаправленное TCP-соединение.

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

Сквозной процесс туннелирования

Рассмотрим пошаговый процесс:

1. Клиент инициирует CONNECT: Браузер (или любое другое приложение, настроенное на использование прокси) формирует CONNECT запрос для https://www.example.com/. Он отправляет его прокси-серверу на порт 8080 (или любой другой порт прокси).
   Client ---- CONNECT www.example.com:443 ----> Proxy
2. Прокси устанавливает соединение: Прокси-сервер получает запрос, парсит его и пытается установить TCP-соединение с www.example.com на порт 443.
   Proxy ---- TCP SYN ----> www.example.com:443 Proxy <--- TCP SYN-ACK --- www.example.com:443 Proxy ---- TCP ACK ----> www.example.com:443
3. Прокси отвечает клиенту: Если соединение с www.example.com успешно установлено, прокси отправляет клиенту HTTP/1.1 200 Connection established.
   Client <--- 200 Connection established --- Proxy
4. Клиент начинает TLS-рукопожатие: Получив подтверждение от прокси, клиент начинает TLS-рукопожатие непосредственно с www.example.com. Прокси-сервер просто передает эти зашифрованные байты.
   Client ---- TLS ClientHello (encrypted) ----> Proxy ----> www.example.com:443 Client <--- TLS ServerHello (encrypted) <---- Proxy <---- www.example.com:443 ... и так далее, до завершения TLS-рукопожатия ...
5. Туннелирование зашифрованного трафика: После успешного TLS-рукопожатия весь последующий HTTPS-трафик между клиентом и www.example.com передается через прокси в зашифрованном виде. Прокси-сервер функционирует как простой ретранслятор пакетов.
   Client <--- Encrypted HTTP data <---> Proxy <---> Encrypted HTTP data ---> www.example.com

Применение и типы прокси

Метод CONNECT универсален и может использоваться не только для HTTPS, но и для любого другого протокола, работающего поверх TCP (например, FTP, SSH), если прокси-сервер настроен для их туннелирования.

Forward Proxy

Это наиболее распространенный сценарий использования CONNECT. Клиенты в локальной сети или за фаерволом используют forward proxy для доступа к внешним ресурсам. Прокси-сервер действует как посредник, пересылая запросы от внутренних клиентов к внешним серверам. CONNECT позволяет этим клиентам безопасно устанавливать зашифрованные соединения с внешними HTTPS-серверами.

Reverse Proxy

Reverse proxy обычно используется для защиты веб-серверов, балансировки нагрузки или кэширования. В этом случае reverse proxy сам обычно терминирует SSL/TLS-соединение с клиентом, а затем устанавливает новое соединение с внутренним сервером. Метод CONNECT здесь не применяется, так как reverse proxy активно участвует в обработке HTTPS-трафика, а не просто туннелирует его.

Transparent Proxy

Transparent proxy перехватывает трафик без явной настройки прокси на стороне клиента. Для HTTP он работает путем изменения адреса назначения пакета. Для HTTPS transparent proxy не может просто туннелировать трафик, так как клиент не знает о его существовании и не отправляет CONNECT запрос. Чтобы перехватывать HTTPS-трафик, transparent proxy должен выполнять SSL/TLS-перехват (MITM), что требует установки доверенного корневого сертификата прокси на стороне клиента. Это фундаментально отличается от работы CONNECT.

Безопасность и конфиденциальность

Использование CONNECT для HTTPS имеет несколько важных аспектов безопасности:

• Конфиденциальность данных: Поскольку TLS-соединение устанавливается непосредственно между клиентом и целевым сервером, прокси-сервер не может дешифровать или просматривать содержимое трафика. Это обеспечивает конфиденциальность данных, передаваемых через прокси.
• Метаданные: Прокси-сервер, тем не менее, имеет доступ к метаданным соединения:
  • IP-адрес клиента.
  • Целевой хост и порт (из CONNECT запроса).
  • Время начала и окончания соединения.
  • Объем переданных данных.
    Эти метаданные могут быть записаны в логи прокси.
• SSL/TLS-перехват (MITM): Некоторые прокси-серверы могут быть настроены для выполнения SSL/TLS-перехвата. В этом случае прокси генерирует свой собственный сертификат для целевого сайта и предъявляет его клиенту. Для успешного перехвата клиент должен доверять корневому сертификату прокси. Если клиент не доверяет, он получит предупреждение безопасности. Это не является стандартным использованием CONNECT для туннелирования, а скорее механизмом для инспекции зашифрованного трафика.

CONNECT в HTTP/2 и HTTP/3

Концепция туннелирования через прокси остается актуальной и в более новых версиях HTTP.

HTTP/2 CONNECT

В HTTP/2 метод CONNECT используется несколько иначе, поскольку HTTP/2 мультиплексирует несколько потоков данных по одному TCP-соединению. Вместо установления нового TCP-соединения для каждого туннеля, CONNECT в HTTP/2 использует отдельный поток (stream) для туннеля. Клиент отправляет запрос CONNECT как обычный HTTP/2 запрос с псевдозаголовками (например, :method: CONNECT, :scheme: https, :authority: www.example.com:443). После получения 200 Connection established от прокси, этот поток становится двунаправленным туннелем для сырых байтов.

HTTP/3 CONNECT

HTTP/3, основанный на QUIC, использует UDP вместо TCP. Метод CONNECT для HTTP/3 пока находится в стадии разработки (например, через механизм EXTENDED CONNECT в черновиках RFC). Основная идея остается той же: создать способ для клиента запросить у прокси туннелирование трафика к целевому хосту и порту, но с учетом особенностей QUIC (потоки, отсутствие блокировки заголовков).

Клиентская конфигурация

Большинство современных веб-браузеров и HTTP-клиентов поддерживают использование прокси с методом CONNECT.

Пример curl с прокси

curl -x http://proxy.example.com:8080 https://www.google.com

В этом примере curl автоматически определит, что https://www.google.com требует HTTPS, и отправит CONNECT www.google.com:443 запрос к http://proxy.example.com:8080.

Пример настройки браузера (концептуально)

В настройках сети браузера указывается адрес и порт HTTP-прокси-сервера. Браузер затем самостоятельно управляет отправкой CONNECT запросов для HTTPS-соединений.

Настройка	Значение
Тип прокси	HTTP-прокси
Адрес прокси	proxy.example.com
Порт прокси	8080
Использовать для	HTTP, HTTPS, FTP (обычно)

Заключение

Метод HTTPS CONNECT является краеугольным камнем для безопасного и эффективного взаимодействия клиентов с зашифрованными веб-ресурсами через прокси-серверы. Он обеспечивает необходимый баланс между возможностью использования прокси для сетевого контроля и сохранением конфиденциальности end-to-end шифрования. Понимание его работы критически важно для проектирования и эксплуатации сетевой инфраструктуры.