HTTP CONNECT

HTTP CONNECT — это метод HTTP, используемый для установления двустороннего туннеля через прокси-сервер. Он предназначен для передачи данных произвольного протокола (чаще всего зашифрованного, например, HTTPS) между клиентом и целевым сервером, минуя прямое соединение. Метод определён в спецификации HTTP/1.1 (RFC 7231) и является частью стандартного набора команд протокола.

Принцип работы

Обычные HTTP-запросы (GET, POST и другие) передаются через прокси-сервер, который выступает в роли посредника: он получает запрос от клиента, сам обращается к целевому серверу и возвращает ответ. Метод CONNECT работает иначе. Клиент отправляет прокси-серверу запрос, содержащий имя целевого хоста и номер порта (например, CONNECT example.com:443 HTTP/1.1). Прокси-сервер, если он настроен разрешать такие запросы, устанавливает TCP-соединение с указанным хостом и портом. После успешного соединения прокси-сервер возвращает клиенту ответ с кодом 200 Connection Established. С этого момента прокси-сервер перестаёт анализировать содержимое передаваемых данных и просто пересылает байты между клиентом и целевым сервером в обе стороны. Таким образом образуется прозрачный туннель, через который может передаваться любой протокол, работающий поверх TCP.

Назначение и применение

HTTPS и защищённые соединения

Основная область применения метода CONNECT — организация доступа к HTTPS-сайтам через HTTP-прокси. Поскольку трафик HTTPS зашифрован, прокси-сервер не может прочитать его содержимое и, следовательно, не может выполнить обычный запрос GET или POST от имени клиента. Метод CONNECT позволяет прокси-серверу просто передать зашифрованный поток данных, не вмешиваясь в него. Клиент устанавливает защищённое TLS-соединение уже непосредственно с целевым сервером через установленный туннель.

Другие протоколы

Хотя CONNECT чаще всего используется для HTTPS, технически он может туннелировать любой TCP-трафик. Это позволяет использовать его для доступа к ресурсам по протоколам FTPS, SSH, WebSocket (через защищённое соединение) и другим. Однако на практике многие прокси-серверы ограничивают использование CONNECT только портами, традиционно ассоциированными с HTTPS (443), и иногда с другими безопасными протоколами (например, 563 для NNTP поверх TLS).

Структура запроса и ответа

Запрос

Запрос CONNECT имеет следующий формат: `` CONNECT <хост>:<порт> HTTP/1.1 Host: <хост>:<порт> [другие заголовки] ``

• Хост — доменное имя или IP-адрес целевого сервера.
• Порт — номер порта на целевом сервере (обычно 443 для HTTPS).
• Host — обязательный заголовок, повторяющий хост и порт.

Пример запроса: `` CONNECT example.com:443 HTTP/1.1 Host: example.com:443 User-Agent: Mozilla/5.0 ``

Ответ

При успешном установлении соединения прокси-сервер отвечает: `` HTTP/1.1 200 Connection Established [другие заголовки] ` После этого начинается передача данных через туннель. Если прокси-сервер не может установить соединение с целевым хостом, он возвращает код ошибки, например 502 Bad Gateway или 403 Forbidden`.

Ограничения и безопасность

Аутентификация

Многие прокси-серверы требуют аутентификации перед разрешением использования метода CONNECT. Это может быть реализовано через заголовок Proxy-Authorization в запросе CONNECT.

Фильтрация портов

Администраторы прокси-серверов часто ограничивают порты, для которых разрешён CONNECT, чтобы предотвратить использование прокси для доступа к нежелательным сервисам (например, к почтовым серверам или к серверам, не использующим шифрование). Типичная практика — разрешать CONNECT только на порт 443 и, возможно, на несколько других портов, используемых для защищённых протоколов.

Уязвимости и злоупотребления

Метод CONNECT может быть использован для обхода корпоративных или региональных ограничений доступа. Например, пользователь может установить туннель к серверу за пределами сети, который затем будет выступать в роли прокси для других протоколов. Это делает CONNECT объектом внимания системных администраторов и разработчиков средств сетевой безопасности. Кроме того, некоторые вредоносные программы используют CONNECT для связи с командными серверами, маскируя свой трафик под HTTPS.

HTTP CONNECT и HTTP/2

В протоколе HTTP/2 метод CONNECT также поддерживается, но его реализация отличается. Вместо установления отдельного TCP-соединения для каждого туннеля, HTTP/2 использует механизм потоков (streams) внутри одного мультиплексированного соединения. Это позволяет создавать несколько туннелей одновременно без затрат на установку новых TCP-соединений. Для HTTP/2 существует также расширение CONNECT-UDP (RFC 9298), которое позволяет туннелировать UDP-трафик, что важно для таких протоколов, как HTTP/3 и DNS поверх HTTPS.

Альтернативы

SOCKS-прокси

Протокол SOCKS (версии 4 и 5) предоставляет более общий механизм для туннелирования TCP-трафика, не привязанный к HTTP. SOCKS5 также поддерживает UDP и аутентификацию. В отличие от HTTP CONNECT, SOCKS работает на более низком уровне и не требует от клиента отправки HTTP-заголовков.

VPN

Виртуальные частные сети (VPN) обеспечивают туннелирование на уровне IP или канала передачи данных, шифруя весь трафик устройства, а не только отдельные соединения. Это более мощный, но и более сложный в настройке инструмент.

Реализация в программном обеспечении

Метод CONNECT поддерживается практически всеми современными HTTP-клиентами и библиотеками:

• Браузеры: Chrome, Firefox, Safari, Edge — используют CONNECT для доступа к HTTPS-сайтам через HTTP-прокси.
• Библиотеки: cURL, libcurl, Python Requests, Java URLConnection и другие.
• Серверное ПО: Squid, Nginx (с модулем ngx_http_proxy_connect_module), HAProxy, Apache Traffic Server и другие прокси-серверы.

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

Источники

• RFC 7231 — Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
• RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2)
• RFC 9298 — Proxying UDP in HTTP
• Документация прокси-сервера Squid
• Документация библиотеки cURL