TLS Inspection

How it works

TLS inspection, also called SSL inspection or TLS bumping, is the practice of having a forward proxy terminate an encrypted connection, read the plaintext, and then open a second encrypted connection onward to the real destination. Two connections exist where the user believes there is one, and the proxy sits in the clear in the middle.

It works only because the client trusts a certificate authority you control. The proxy generates a certificate for the destination on the fly, signs it with your organization's root certificate authority, and the client accepts it because that root was installed on the device. Remove the root, and the connection fails immediately with a certificate error. That dependency is the whole basis of the control, and it is also its boundary.

When it matters

It matters when a security requirement genuinely cannot be met from metadata alone: data loss prevention on web uploads, malware scanning of downloaded files, or detecting exfiltration inside API payloads. Destination-based policy answers "where did this go." Only inspection answers "what was in it."

It should be deployed with three things in place, and if you cannot supply all three you should not deploy it: managed devices where you control the trust store, a written bypass list, and a retention policy you can defend to the people whose traffic you are reading.

Common misconceptions

• "TLS inspection means we can see everything." Only on devices whose trust store you control, and never against an application that pins its certificate. Certificate-pinned applications do not fall back to an inspectable connection, they fail outright, which is why they must be bypassed rather than inspected.
• "It is just a firewall feature to switch on." It is a governance decision with a technical implementation. Categories such as banking, health, and legal are bypassed for privacy and sometimes legal reasons, and employees are normally entitled to know the practice exists.
• "Encrypted Client Hello has killed it." ECH, published as RFC 9849 in March 2026, encrypts the server name in the handshake and so removes a metadata signal that gateways rely on. It does not affect an explicit proxy that terminates TLS on a managed device. Measured adoption also remains very small, so this is planned work rather than an emergency.