An SSL proxy — also referred to as a Man-in-the-Middle (MITM) proxy — is an intermediary device that intercepts encrypted HTTPS connections between a client and a destination server.

Rather than communicating directly with the destination, the browser connects to the proxy. The proxy decrypts the inbound HTTPS traffic, inspects or filters it according to a defined policy, re-encrypts it, and forwards the reconstructed connection to the intended server.

From the perspective of the destination server, the connection appears to originate from the proxy — not from the end-user's device. This process is formally known as SSL/TLS interception or HTTPS inspection.

SSL interception is legitimately deployed across a wide range of enterprise and security use cases. Understanding these use cases helps distinguish authorised inspection from unauthorised interception.

Detection is based on TLS fingerprint analysis of the ClientHello message — the first packet a browser sends when initiating a secure connection. This message is transmitted before encryption is established, making it fully observable without breaking the security of the session.

3.1 — The TLS ClientHello

When a browser initiates a TLS handshake, it sends a ClientHello message containing a structured description of its TLS capabilities. The fields within this message collectively form a TLS fingerprint that is characteristic of a specific browser and its underlying TLS implementation.

These fields together form a fingerprint that is highly consistent for a given browser version. Modern fingerprinting methods such as JA3, JA3S, and JA4 hash these fields to produce a short identifier that can be compared against known browser profiles.

3.2 — Cross-Validation Against the User-Agent

Once the server captures the raw ClientHello fingerprint, it cross-validates the observed TLS characteristics against the browser identity declared in the HTTP User-Agent string.

Modern browsers generate consistent, recognisable TLS fingerprints that match their declared identity. When a middlebox intercepts the connection and rebuilds the TLS handshake using its own TLS library — such as OpenSSL, Go's crypto/tls, or a vendor-specific stack — the resulting ClientHello structure changes. These structural differences create detectable inconsistencies between the expected browser fingerprint and the observed handshake.

3.3 — Why Certificate Spoofing Cannot Bypass This Detection

Many SSL interception systems install a trusted root certificate on the endpoint device to prevent certificate warnings. This makes certificate-based detection methods ineffective — the proxy can present a trusted certificate that the browser accepts without complaint.

However, TLS fingerprint analysis operates at the handshake layer, before certificate exchange completes. Even when a proxy presents a fully trusted certificate, it cannot perfectly replicate the client TLS fingerprint because:

• Cipher suite ordering is determined by the underlying TLS library, not configurable per-session
• Extension ordering and contents are library-specific and structurally different across implementations
• GREASE values are generated by the browser's TLS stack and are not inserted by proxy libraries
• ALPN preferences reflect the browser's actual HTTP implementation, not the proxy's
• Supported version lists differ between browser TLS stacks and proxy TLS libraries

The following five signals are examined during fingerprint analysis. Each represents a structural property of the ClientHello that differs predictably between genuine browser connections and proxy-reconstructed handshakes.

A summary of all five detection signals and their expected values for legitimate browsers versus proxy-intercepted connections.

The detection engine cross-references all observed signals against the declared browser profile. Results fall into one of two categories: