Wyjaśnienie metody HTTP CONNECT

Zwykły proxy HTTP działa, odczytując Twoje żądanie, pobierając zasób i zwracając go — widzi i przekazuje pełne żądanie i odpowiedź. To działa w przypadku zwykłego HTTP, ale nie sprawdza się w przypadku HTTPS: cały sens TLS polega na tym, że żaden pośrednik nie może odczytać ruchu, więc proxy nie może po prostu "pobierać strony" w Twoim imieniu bez łamania szyfrowania.

Metoda CONNECT rozwiązuje ten problem. Zamiast prosić proxy o pobranie czegoś, Twój klient prosi proxy o otwarcie surowego tunelu TCP do hosta i portu, a następnie ustępuje miejsca. Gdy tunel jest otwarty, Twój klient wykonuje handshake TLS bezpośrednio z docelowym przez proxy, a proxy bezwiednie przekazuje zaszyfrowane bajty w obu kierunkach. Proxy nigdy nie widzi tekstu jawnego — widzi tylko nieprzezroczysty strumień i, za pośrednictwem linii CONNECT oraz TLS SNI, nazwę hosta docelowego. Tak działa s4m proxy HTTP na porcie 3128 dla HTTPS.

Przepływ jest krótki i konkretny:

1. Twój klient wysyła CONNECT example.com:443 HTTP/1.1 do proxy, z nagłówkiem Host i, jeśli to konieczne, z poświadczeniami Proxy-Authorization.
2. Proxy otwiera połączenie TCP do example.com:443.
3. Jeśli to się powiedzie, proxy odpowiada HTTP/1.1 200 Połączenie nawiązane. Od tego momentu połączenie jest czystym tunelem — bez dalszej semantyki HTTP.
4. Twój klient teraz przeprowadza handshake TLS bezpośrednio z example.com przez ten tunel, a wszystkie następne dane aplikacji są szyfrowane end-to-end.

Z tego wynikają dwie konsekwencje. Po pierwsze, TLS pozostaje prawdziwie end-to-end: proxy nic nie uwierzytelnia i nic nie odczytuje wewnątrz tunelu, więc walidacja certyfikatu odbywa się między twoim klientem a prawdziwym serwerem. Po drugie, ponieważ CONNECT po prostu otwiera tunel TCP, proxy mogą w zasadzie tunelować inne protokoły oparte na TLS lub dowolne inne protokoły na innych portach — co jest dokładnie powodem, dla którego proxy zazwyczaj ograniczają CONNECT do portu 443 (i kilku innych), aby uniknąć stania się otwartym przekaźnikiem.