A forward TLS-inspecting proxy sits between the client and the open internet as two separate, independently negotiated TLS sessions rather than one continuous encrypted pipe:
Client ⇄TLS-1⇄ Proxy ⇄TLS-2⇄ Server
TLS-1: proxy presents a leaf cert signed by an
internal CA the client already trusts
(pushed via MDM / group policy).
TLS-2: proxy acts as a normal TLS client toward
the real origin, validating ITS chain
normally (hostname, expiry, revocation).
Because the proxy terminates TLS-1 itself, it holds the plaintext for the short window between the two sessions and can classify it — malware/C2 signatures, DLP rules, content category, tracker domains — before deciding whether to re-encrypt and forward on TLS-2, or drop the connection.
decision(pkt) =
ALLOW if inspect=off
BLOCK if inspect=on AND category ∈ policy.blocked
ALLOW if inspect=on AND category ∉ policy.blocked
added_latency ≈ t(decrypt) + t(classify) + t(re-encrypt)
- Inspection off — the tunnel stays opaque end-to-end; the proxy forwards bytes it cannot read, so a malicious or policy-violating connection sails through unseen. This is the real trade-off orgs weigh: visibility vs. the added trust concentrated in one CA and one box.
- Inspection on — every connection is classified against the active policy toggles before being re-encrypted toward the server, at the cost of processing latency and a privacy footprint the proxy operator must handle responsibly (logging scope, retention, exempting banking/health traffic).
- Threats caught counts connections that inspection correctly blocked; blind bypass counts connections that would have matched a block rule but slipped through because inspection was off — the concrete cost of flying blind.