HTTP CONNECT and HTTPS Proxy Tunnels: TLS Boundaries and Handshake Latency

When a client system reaches a secure HTTPS origin through an HTTP forward proxy, standard cleartext request forwarding is impossible. To preserve end-to-end TLS encryption and integrity, the proxy cannot act as a Layer 7 TLS terminator (unless explicitly configured for SSL Bumping). Instead, the client issues an HTTP CONNECT request, initiating a protocol transition. The proxy effectively demotes itself to a Layer 4 TCP byte-shoveler. Understanding the kernel-level mechanics, queueing theory, and socket-buffer management behind this transition is essential for designing high-throughput edge proxies.

1. The Mechanics of HTTP CONNECT: State Machine Transition

Under RFC 9110, CONNECT converts an HTTP connection into a raw TCP/IP transparent tunnel. In high-performance reverse proxies like Nginx or HAProxy, the event loop (e.g., epoll) processes the HTTP headers, parses the target authority, issues an asynchronous non-blocking connect() to the origin, and upon receiving the EPOLLOUT event, sends the 200 Connection Established response to the client. From this moment on, the HTTP state machine is destroyed, and the socket file descriptors (FDs) are chained together for raw binary forwarding.

Mermaid Diagram: Advanced Connection Flow

sequenceDiagram
    participant Client
    participant Proxy (Kernel/User)
    participant Origin Server
    
    Note over Client, Proxy (Kernel/User): 1. Proxy TCP Handshake & Queueing
    Client->>Proxy (Kernel/User): TCP SYN
    Proxy (Kernel/User)->>Client: TCP SYN-ACK
    
    Note over Client, Proxy (Kernel/User): 2. HTTP CONNECT & DNS
    Client->>Proxy (Kernel/User): CONNECT origin.example:443 HTTP/1.1
    Proxy (Kernel/User)->>Proxy (Kernel/User): NSS getaddrinfo() / Async DNS
    Proxy (Kernel/User)->>Origin Server: TCP SYN (Non-blocking)
    Origin Server->>Proxy (Kernel/User): TCP SYN-ACK
    Proxy (Kernel/User)->>Client: HTTP/1.1 200 Connection Established
    
    Note over Client, Origin Server: 3. Zero-Copy TLS Tunneling (splice syscall)
    Client->>Proxy (Kernel/User): TLS Client Hello (SNI)
    Proxy (Kernel/User)->>Origin Server: splice(client_fd, origin_fd)
    Origin Server->>Proxy (Kernel/User): TLS Server Hello, Cert
    Proxy (Kernel/User)->>Client: splice(origin_fd, client_fd)
    
    Note over Client, Origin Server: 4. Encrypted Application Data
    Client->>Origin Server: Encrypted AES-GCM Frames
    Origin Server->>Client: Encrypted AES-GCM Frames

2. Advanced Proxy Architecture: Zero-Copy and splice()

At massive scale, reading bytes into user-space buffers via read() and immediately writing them out via write() incurs devastating CPU context-switch overhead and memory bus saturation. High-throughput proxies (like HAProxy) utilize the Linux splice() system call for the CONNECT tunnel.

splice() moves data between two file descriptors entirely within kernel space, provided one is a pipe. HAProxy allocates a pipe, splices the client TCP socket into the pipe, and then splices the pipe into the origin TCP socket. This “zero-copy” architecture allows an edge node to push tens of gigabits per second of TLS tunneled traffic with near-zero user-space CPU utilization.

3. Mathematical Rigor: Queueing Theory and Little’s Law

Connection latency through a proxy is governed by queueing theory. If the proxy handles a request arrival rate of \(\lambda\) (connections per second), and the average time to establish the backend TCP connection is \(W\), the number of concurrent pending connections \(L\) waiting in the proxy’s state machine is modeled by Little’s Law:

\[ L = \lambda W \]

If the backend origin becomes congested, \(W\) spikes. Without aggressive timeout configurations or circuit breakers, \(L\) will exhaust the proxy’s ephemeral port range (TCP tuple exhaustion) or file descriptor limits (ulimit -n), causing a cascading failure. Engineers must model the proxy as an \(M/M/c\) queueing system, where \(c\) is the number of available worker threads or async event loops, calculating the Erlang C blocking probability to size the proxy fleet adequately.

4. Advanced Tooling: eBPF Traffic Interception and Metrics

To measure true CONNECT latency decoupled from the TLS handshake, SREs employ XDP (eXpress Data Path) or eBPF kprobes on the kernel’s tcp_v4_connect and tcp_rcv_state_process functions.

#include <bcc/proto.h>
#include <net/sock.h>

// Trace tcp_connect to track proxy-to-origin latency
int kprobe__tcp_connect(struct pt_regs *ctx, struct sock *sk) {
    u32 pid = bpf_get_current_pid_tgid();
    u64 ts = bpf_ktime_get_ns();
    // Store socket pointer and timestamp
    bpf_map_update_elem(&connect_start, &sk, &ts, BPF_ANY);
    return 0;
}

By mapping the kernel socket structs back to the HAProxy PIDs, you can generate histograms of kernel-level TCP RTTs, bypassing any user-space scheduling jitter.

5. Post-Mortem: SSL Bumping and Egress Policies

Corporate NGFWs (Next-Generation Firewalls) often perform “SSL Bumping.” The firewall intercepts the CONNECT, acts as the origin, terminates the TLS session, inspects the plaintext HTTP payload, and re-encrypts it using a dynamically generated certificate signed by a corporate Root CA. If the client lacks this Root CA in its trust store, the TLS handshake fails with X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN.

Furthermore, secure egress architectures must enforce strictly whitelisted CONNECT ACLs. Unrestricted CONNECT methods are notoriously exploited by attackers to bounce traffic via the proxy to internal VPC endpoints (e.g., CONNECT 10.0.0.5:22), weaponizing the proxy as an internal network pivot.

6. CONNECT Troubleshooting Table

CONNECT tunnel failures often look identical from the browser: a spinner, a timeout, or a generic proxy error. The evidence below separates proxy authorization, tunnel establishment, TLS negotiation, and upstream reachability.

References

• RFC 9110 Section 9.3.6: HTTP Semantics – CONNECT
• Linux Programmer’s Manual: splice(2)