skip to content

Explain what the HTTP CONNECT method does, how a browser uses it to reach an HTTPS site through a forward proxy, and what the proxy can and cannot observe once the tunnel is established.

level: seniorimportance: should knowfreq 35%

answer

  1. Authority-form target: host:port, no path
  2. 200 Connection Established, then raw bytes
  3. TLS handshake end-to-end past the proxy
  4. Proxy sees host/port/SNI/timing only
  5. 407 + Proxy-Authorization; allow-list ports

basics

~20 s

CONNECT asks a proxy to open a raw TCP connection to a host:port and then relay bytes blindly. The browser sends CONNECT example.com:443, gets 200, then performs TLS end-to-end through the tunnel. The proxy sees host, port, timing and byte counts — not URLs, headers, or bodies.

solid answer

~50 s

**CONNECT turns a proxy into a byte pipe.** The client sends `CONNECT example.com:443 HTTP/1.1` with an authority (host:port), not a URI path. The proxy opens a TCP connection to that host and port and replies `200 Connection Established` with no body. From that point the HTTP framing is over: everything the client writes is relayed verbatim. The browser then runs the **TLS handshake end-to-end with the origin** inside the tunnel, so the origin's certificate is validated by the browser, not the proxy. The proxy therefore sees only the target host and port (from the CONNECT line, echoed in TLS SNI), connection timing, and byte volumes — no request line, no headers, no cookies, no body. Proxy authentication happens before the tunnel: `407 Proxy Authentication Required` plus `Proxy-Authorization`. CONNECT is not safe, not idempotent, and not cacheable. Operationally the key control is restricting the allowed ports — an unrestricted CONNECT proxy is an open relay and a port scanner.

code

http · 7 lines
http
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic ZGV2OnMzY3JldA==

HTTP/1.1 200 Connection Established

<TLS ClientHello and all subsequent bytes are relayed verbatim>

go deeper

for a junior

Know that CONNECT asks a proxy to open a raw tunnel so HTTPS can pass through, and that the proxy then just relays bytes it cannot read.

for a middle

Walk the exchange precisely: authority-form target, 200 Connection Established with no body, TLS handshake end-to-end afterwards, 407 and Proxy-Authorization for proxy auth.

for a senior

Draw the visibility boundary explicitly — host, port, SNI, timing, byte counts versus nothing above TLS — and cover open-relay and internal-scan risk with port allow-listing and private-range denial.

for a principal

Frame it as a policy tradeoff: plain CONNECT preserves end-to-end confidentiality but limits enforcement to hostname granularity, while interception buys inspection at the cost of concentrating all plaintext and all trust in one appliance that pinning will break.

## What CONNECT is for Every other HTTP method asks a server to act on a resource. `CONNECT` asks an intermediary to **stop being an HTTP server and become a TCP relay**. It exists because a forward proxy cannot read or rewrite an encrypted HTTPS exchange, yet the client still needs the proxy to reach the network. The request target is *authority-form* — a host and a port, with no scheme and no path: ``` CONNECT example.com:443 HTTP/1.1 Host: example.com:443 ``` The proxy resolves the host, opens a TCP connection to that port, and on success replies with a 2xx — conventionally `200 Connection Established` — and **no message body**. There is no `Content-Length`; whatever follows the blank line is tunnel payload, not HTTP. ## The browser flow 1. Browser is configured with a proxy (PAC file, system settings, corporate policy) and needs `https://example.com/orders`. 2. It sends `CONNECT example.com:443` to the proxy. If the proxy demands credentials it answers `407 Proxy Authentication Required` with `Proxy-Authenticate`; the browser retries with `Proxy-Authorization`. 3. Proxy answers `200 Connection Established`. 4. The browser now performs a **TLS handshake with example.com**, through the tunnel. It validates example.com's certificate itself. 5. Inside TLS, it sends the ordinary request: `GET /orders HTTP/1.1`, cookies, tokens and all. Note the split: the CONNECT exchange in step 2 is plaintext between browser and proxy; everything from step 4 on is ciphertext the proxy merely copies between two sockets. ## What the proxy can and cannot see **Can see:** the target hostname and port (from the CONNECT line, and again from the TLS SNI extension unless Encrypted Client Hello is in use), the client's IP, connection open/close times, bytes in each direction, packet timing — enough for logging, quota accounting, and hostname-based allow/deny policy, and enough for traffic analysis to infer a lot. **Cannot see:** the request method, path, query string, headers, cookies, `Authorization` tokens, request or response bodies, or status codes. It also cannot cache anything, cannot compress, cannot rewrite headers, and cannot apply content inspection. This is exactly why organisations that *want* inspection deploy a **TLS-intercepting proxy**: the proxy terminates TLS itself, presents a certificate signed by a private CA that has been installed on every managed device, and opens a second TLS connection onward. The client only accepts this because the interception CA is trusted locally; certificate pinning breaks it deliberately. Interception is a policy decision with real costs — it concentrates every user's plaintext at one box. ## Security and operations An unrestricted CONNECT proxy is a serious liability. If it will tunnel to arbitrary host:port pairs it becomes: - an **open relay** (tunnel to port 25 and send spam that appears to originate from you), - a **port scanner and internal-network probe** — CONNECT to `10.0.0.5:6379` and the tunnel's success or failure reveals whether an internal service is listening, - an **anonymiser** laundering someone else's traffic through your IP. The standard controls: authenticate proxy clients; allow-list destination ports (typically 443, sometimes 22 for deliberate use cases); block RFC 1918 and link-local destinations to blunt SSRF-style pivoting; rate-limit tunnel establishment; and log the CONNECT authority for audit. Note also that the proxy's `200` only means the TCP connection succeeded — it says nothing about the origin being healthy at the application layer. ## Method properties and newer versions CONNECT is neither safe nor idempotent (each one establishes a new connection consuming resources) and responses are never cacheable. Hop-by-hop proxy headers such as `Proxy-Authorization` apply to the CONNECT exchange only, not inside the tunnel. In **HTTP/2 and HTTP/3** there is no request line: CONNECT is expressed as a stream with `:method: CONNECT` and `:authority: example.com:443`, and `:scheme`/`:path` omitted. The tunnel occupies one stream, so several tunnels can share a single connection. **RFC 8441** adds *extended CONNECT* (`:protocol: websocket`), which is how WebSockets are carried over HTTP/2 rather than via the HTTP/1.1 `Upgrade` handshake. The MASQUE work builds on the same idea with CONNECT-UDP and CONNECT-IP over HTTP/3 for proxying non-TCP traffic. ## The one-sentence version CONNECT trades away every HTTP capability the proxy has — caching, inspection, rewriting — in exchange for letting encrypted traffic pass through it end-to-end.

  • If the proxy cannot read the encrypted traffic, how do corporate proxies still enforce URL-level filtering policy?
    Either coarsely or by interception. Coarsely, they filter on the CONNECT authority and the TLS SNI hostname, which is all the metadata a plain tunnel exposes — that blocks whole hosts but not individual paths. For path-level policy they deploy a TLS-intercepting proxy that terminates TLS with a certificate signed by a private CA pre-installed on managed devices, inspects the plaintext, then opens a second TLS connection to the origin. Certificate pinning in an application defeats this on purpose.
  • Why must a CONNECT proxy restrict which destination ports it will tunnel to?
    Because an unrestricted tunnel makes the proxy a general-purpose relay for someone else's traffic. Tunnelling to port 25 turns it into a spam relay attributed to your IP; tunnelling to internal addresses lets an outsider port-scan and reach services that were never meant to be exposed, since even a failed connection leaks whether something is listening. The standard posture is an allow-list of ports plus a deny-list of private address ranges, combined with proxy authentication.
  • What does a 200 Connection Established actually guarantee?
    Only that the proxy successfully opened a TCP connection to the requested host and port. It says nothing about TLS succeeding, about the origin's certificate being valid, or about the application behind that port being healthy. Those failures surface later, inside the tunnel, as TLS or application errors the proxy never sees.

CONNECT is asking a switchboard operator to patch your line straight through: they know who you called and how long you talked, but once connected they hear nothing of the conversation.

saying these in an interview costs you the question

  • Claiming the proxy can see the requested URL path or headers after a CONNECT tunnel is established
  • Saying the proxy terminates TLS by default — that is interception, which requires a trusted private CA on the client
  • Treating CONNECT as safe or idempotent, or expecting the response to be cacheable
  • Believing CONNECT is only an HTTP/1.1 concept and does not exist in HTTP/2 or HTTP/3
  • Running an open CONNECT proxy without destination port restrictions or authentication

context

resolving links…