Метод HTTP CONNECT: как он работает

Обычный HTTP-прокси работает так: читает ваш запрос, забирает ресурс и возвращает его вам — то есть видит и перегоняет весь запрос и весь ответ. Для чистого HTTP это нормально, но с HTTPS ломается: весь смысл TLS в том, что ни один посредник не читает трафик, поэтому прокси не может просто «сходить за страницей» вместо вас, не сломав шифрование.

Метод CONNECT решает это. Вместо того чтобы просить прокси что-то достать, ваш клиент просит его открыть сырой TCP-туннель к хосту и порту и отойти в сторону. Как только туннель открыт, клиент выполняет TLS-рукопожатие напрямую с назначением через прокси, а прокси вслепую перегоняет шифрованные байты в обе стороны. Открытого текста он не видит — только непрозрачный поток и, из строки CONNECT и SNI в TLS, имя хоста назначения. Именно так HTTP-прокси s4m на порту 3128 носит HTTPS.

Схема короткая и конкретная:

1. Ваш клиент отправляет прокси CONNECT example.com:443 HTTP/1.1 с заголовком Host и, если нужно, учётными данными в Proxy-Authorization.
2. Прокси открывает TCP-соединение к example.com:443.
3. Если получилось, прокси отвечает HTTP/1.1 200 Connection Established. С этого момента соединение — голый туннель, никакой семантики HTTP больше нет.
4. Теперь клиент прогоняет TLS-рукопожатие напрямую с example.com через этот туннель, и все дальнейшие данные приложения шифруются сквозным образом.

Отсюда два следствия. Во-первых, TLS остаётся по-настоящему сквозным: прокси ничего не аутентифицирует и ничего не читает внутри туннеля, поэтому сертификат проверяется между вашим клиентом и настоящим сервером. Во-вторых, поскольку CONNECT просто открывает TCP-туннель, прокси в принципе способен протянуть и другие протоколы поверх TLS или вообще любые, на других портах, — именно поэтому прокси обычно ограничивают CONNECT портом 443 (и парой других), чтобы не превратиться в открытый релей.