HTTP CONNECT method: how HTTPS gets through a proxy

Originally published on proxymint.

The HTTP CONNECT method turns a proxy into a blind tunnel. The request, the 200 reply, what the proxy can and cannot see, why tunnels fail, and HTTP/3.

TL;DR

• CONNECT turns an HTTP proxy into a blind tunnel. The client names a host and port, the proxy dials it and answers 200, and from then on it relays bytes in both directions.
• HTTPS stays end to end inside the tunnel. The client runs TLS with the target through the proxy, so the proxy sees the host, port, timing and byte counts, never paths, headers or page content.
• The status of the CONNECT reply says which hop broke. A 407, 403 or 502 means the tunnel never opened; a 200 followed by a TLS error is a problem between the client and the site.
• HTTP/3 needs CONNECT-UDP. A classic CONNECT tunnel carries TCP only, so clients behind it fall back to HTTP/2 or HTTP/1.1.

Key takeaways

• Keep the proxy URL scheme http:// for https:// targets. The client tunnels through CONNECT and runs the site's TLS inside it, which is how HTTPS works through a proxy.
• Read the CONNECT line in curl -v before changing TLS settings. Everything before the 200 is the proxy's side. After it, look at the client and the site first, unless the tunnel drops with a reset or EOF.
• Never disable certificate checks to make a tunnel work. A CONNECT proxy never needs it, and it lets anything in the middle read the traffic.
• Test non-HTTPS ports before relying on them. Proxies restrict CONNECT to known ports, so SSH or mail over an HTTP tunnel often gets a 403.

Read the full guide on proxymint, with the commands, tables and sources.