Glossary

TLS interception

TLS interception is the practice of terminating a client's encrypted connection at a middlebox that reads the plaintext and re-encrypts onward.

TLS interception is the practice of terminating a client’s encrypted connection at a middlebox, reading the plaintext, and opening a second connection onward to the real server. It is two TLS sessions presented to the client as one.

#What has to be true for it to work

The middlebox must present a certificate for the requested name that the client accepts. Certificate validation is defined in RFC 5280, so in practice the operator installs a private root in the client’s trust store and the middlebox issues from it. Without that step the client sees an unknown issuer and refuses.

This is why interception is normal on managed corporate machines and difficult anywhere else. Trust has to be provisioned in advance, on the endpoint.

#What it changes on the wire

The handshake the server sees is the middlebox’s, not the browser’s. Any JA3-style fingerprint now describes the middlebox.
The negotiated parameters may be weaker than either endpoint would have chosen alone, since both halves are constrained by the middlebox’s own implementation.
Client certificates break, because the middlebox does not hold the client’s private key.
Pinning breaks by design. An application that pins refuses the substituted certificate, which is the intended behaviour.

#Checking whether it is happening

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject

If the issuer is a name belonging to your employer, your security appliance or your own machine’s local root, the connection is being intercepted. Compare against the issuer seen from a network you control, because an issuer name alone can be made to look plausible.

This matters when a scraper misbehaves only on one network. An appliance in the path explains a stable set of otherwise baffling symptoms: a fingerprint you did not choose, a protocol version you did not negotiate, and failures confined to one office.

#Commonly confused with

A transparent proxy redirects traffic without client configuration; that alone does not let it read TLS. An HTTP CONNECT proxy carries an encrypted connection without terminating it, so it learns the destination and the byte counts and nothing more. Interception is specifically the case where the middlebox holds both plaintexts.

Frequently asked questions

Can any proxy read my HTTPS traffic?

Only one that terminates the TLS session with a certificate your client accepts, which normally means a root someone installed in your trust store. A CONNECT proxy forwards the encrypted bytes and can see the destination host and the volume of traffic, but not the contents.

Does interception change my TLS fingerprint?

Yes, completely. The handshake reaching the server is produced by the middlebox, so the fingerprint the destination records is the middlebox's rather than your browser's. Anti-bot systems that key on that fingerprint will see the appliance, not the client you configured.

How do I tell whether my corporate network intercepts TLS?

Inspect the certificate chain for a site you know uses a public certificate authority. If the issuer is an internal name, a security vendor or a locally installed root, the session is being terminated on the way. Comparing the same site from an unmanaged network settles it.