Learning outcomes
- Distinguish WebSocket upgrade, HTTP CONNECT, and CONNECT-UDP behavior.
- Bind tunnel authorization to client, target, protocol, and lifetime.
- Prevent arbitrary destinations, forwarding, and post-connect authority expansion.
- Test policy change, revocation, reconnect, failure, and evidence limits.
Protocol roles
WebSocket starts with an HTTP handshake and becomes a bidirectional message channel. CONNECT asks a proxy to establish a tunnel to a target. CONNECT-UDP carries UDP payloads through an HTTP connection. The proxy, client, target, and application protocol retain different responsibilities.
Message flow
Authenticate the client before tunnel establishment. Normalize and authorize the target host, port, protocol, route, and identity. Establish the connection only to configured destinations. Bind the live connection to the decision, enforce lifetime and resource limits, and record connection and target results.
Validation and failure cases
Reject arbitrary authorities, alternate encodings, unapproved ports, DNS changes that escape the intended target, nested forwarding, unsafe WebSocket origins, and client-supplied identity. Test long-lived connection behavior after policy change, identity disablement, certificate change, control outage, and target failover.
Design tradeoffs and residual risk
Tunnels support protocols the proxy cannot interpret and hide application actions. Per-connection policy is efficient and remains stale for the connection lifetime. Reconnecting frequently improves freshness and increases availability and load pressure.
Residual risk includes allowed tunnels carrying harmful protocol actions, direct target paths, DNS rebinding, forwarded destinations, and actions accepted before connection termination.
Pomerium boundary
Pomerium supports documented WebSocket, TCP, UDP, and native SSH paths with protocol-specific requirements. Policy timing differs by path. Operators and upstreams own target restriction, application protocol authorization, connection lifetime, resource control, and direct-path isolation.
Exercise
Create one WebSocket and one CONNECT-based test route. Capture the authorization event, target, connection, and application action. Test wrong target, wrong port, alternate DNS answer, origin mismatch, policy change, identity disablement, idle timeout, reconnect, and direct target access.
Evaluation checklist
- Which request establishes the upgraded or tunneled connection?
- Are client, target, authority, port, protocol, and route bound to policy?
- Which application actions remain opaque after connection establishment?
- When do policy, revocation, and context changes affect the live connection?
- Can DNS, forwarding, or a direct path expand the authorized target?
Next learning unit
WebSocket Access
WebSocket access starts with an HTTP upgrade and then carries long-lived bidirectional messages on one connection.
