Cross a proxy and keep security checks
05A forward proxy still receives ordinary CONNECT. The protocol inside that tunnel determines the WebSocket opening handshake.
Independent example: a site rejects an Origin outside its permitted set, so that WebSocket opening stops at the policy gate. TLS success does not override that decision or authenticate a user.
Source for this drawing: RFC 8441 · Read RFC section 7 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Forward proxy
- An intermediary chosen by the client to relay a tunnel to an external host.
- Origin
- The browser page’s scheme, host and port; this request field is not a user login.
- TLS
- Transport encryption and peer protection for the illustrated wss connection.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Do not confuse the outer proxy tunnel with the inner WebSocket stream.
- For an HTTP/2 forward proxy, use traditional CONNECT without :protocol to tunnel toward the WebSocket server. The resulting HTTP version inside determines whether the extended opening is used.
- In the illustrated wss tunnel, the client establishes TLS to the origin. If HTTP/2 is negotiated inside, that inner peer must provide its own opt-in before Extended CONNECT is used there.
- RFC6455§10 security considerations still apply except the old-handshake-specific §10.8. Origin policy, masking, TLS and application authentication have distinct jobs; a successful tunnel does not log a user in.
Traditional CONNECT field rules are clarified by RFC9113§8.5: :method CONNECT, :authority host:port, no :scheme/:path. RFC8441§8 explains CONNECT/Sec-prefix/pseudo-header protections against cross-protocol browser requests; these are not client authentication. The final state is a separate rejected-Origin example following a site’s local policy. Origin is useful for browser-origin restrictions, not trustworthy identity from arbitrary non-browser clients.
Read the RFC section ↗