TLS Interception: How Corporate Proxies Read Your Encrypted Traffic
Enterprise 'SSL inspection' doesn't break encryption—it relocates the endpoint to a proxy. How TLS interception works, its measured security risks, and how to detect it.
TLS interception, marketed as 'SSL inspection' in enterprise firewalls and secure web gateways, doesn't break HTTPS encryption—it relocates the trusted endpoint. Organizations install their own root CA on managed devices, the proxy terminates the TLS connection, mints a fresh certificate for the requested hostname on the fly, and the browser trusts it because the chain leads back to that installed root. Traffic is encrypted only up to the proxy; from there the proxy sees plaintext and logs it under whatever policy the organization sets.
The security cost is measurable. A 2017 NDSS study by researchers from Mozilla, Google, Cloudflare and academia found most intercepting middleboxes negotiated weaker cryptography than clients originally offered, with some skipping certificate validation entirely—serious enough that US-CERT issued a formal alert. The 2015 Lenovo Superfish scandal and Kazakhstan's 2019-2020 mandatory 'national security certificate,' which browser vendors explicitly blacklisted, show how the same mechanism turns dangerous at consumer and state scale.
For engineers, detection is straightforward: inspect the certificate issuer on managed devices, compare the same site across networks, and watch for certificate-pinning failures. End-to-end encryption remains the one design that survives interception, since message keys never touch the terminating proxy—TLS is only the outer transport layer. Anything that truly needs privacy should rely on end-to-end encryption rather than trust in whoever terminates TLS on someone else's network.