The padlock in your browser tells you the connection is encrypted. It does not tell you who is on the other end of that encryption. On millions of corporate and school devices, the answer is a middlebox in the IT department, decrypting and re-encrypting every HTTPS request before it ever reaches the real website.
TLS interception, sometimes sold as "SSL inspection" or "HTTPS filtering," is a standard feature in enterprise security products. Firewalls and secure web gateways from most major vendors ship with it. The stated purpose is reasonable on its face: malware arrives over HTTPS too, and a filter that cannot see inside encrypted traffic cannot scan it.
What the feature actually does is run a man-in-the-middle attack against every user behind it, with permission from the device owner rather than the person typing. Understanding the mechanics matters, because the same trick shows up in contexts far less benign than a corporate firewall.
How the interception actually works
TLS normally prevents interception because the server proves its identity with a certificate signed by a certificate authority your browser already trusts. A proxy sitting in the middle cannot present a valid certificate for your bank's hostname, so the connection fails.
Enterprise interception solves this by changing the trust store, not by breaking the cryptography. The steps:
- The organization generates its own private root CA and installs it in the trust store of every managed device, usually through mobile device management or Group Policy.
- The proxy terminates your TLS connection and reads the hostname you asked for.
- It mints a fresh certificate for that hostname on the fly, signed by the corporate root, and presents it to your browser.
- Your browser sees a certificate chain ending in a trusted root and shows the padlock.
- The proxy opens its own separate TLS connection to the real server and shuttles data between the two, inspecting everything in between.
From the browser's point of view, nothing is wrong. The cryptography on each leg is intact. What changed is that "end-to-end" now ends at the proxy, and everything you send, including passwords, medical searches, and private messages sent over webmail, is plaintext at that point.
The core distinction: TLS interception does not break encryption. It relocates the endpoint. Your traffic is encrypted to the proxy, and separately from the proxy to the site. The proxy itself sees plaintext, logs whatever it is configured to log, and retains it under whatever policy the organization chose.
The security cost is measurable, not theoretical
A middlebox that terminates TLS also negotiates TLS on your behalf, and it rarely does it as well as your browser would. A 2017 study presented at NDSS, "The Security Impact of HTTPS Interception" by researchers from Mozilla, Google, Cloudflare, and several universities, measured intercepted connections at scale and found that the majority negotiated weaker cryptography than the client originally offered. Some middleboxes accepted broken cipher suites, skipped certificate validation entirely, or advertised support for TLS versions with known attacks.
The finding was serious enough that US-CERT issued alert TA17-075A the same year, warning organizations that HTTPS inspection products "may weaken the protections that TLS is intended to provide" and urging them to verify what their middleboxes actually do with upstream certificates.
The consumer-side version of this failure had already made headlines. In 2015, Lenovo shipped laptops with Superfish adware that installed a root CA to inject ads into HTTPS pages. Every affected laptop carried the same root CA private key, and it was extracted within days of discovery. Anyone on the same network could then impersonate any website to any Superfish-infected machine. The certificate that made ads possible made banking fraud possible too.
When the "enterprise" is a government
The technique scales past companies. In 2019, and again in 2020, Kazakhstan instructed citizens to install a government-issued "national security certificate" as a condition of internet access in parts of the country. With that root installed, the state could intercept HTTPS traffic to any site it chose. Browser vendors responded by hard-blocking the certificate: Chrome, Firefox, and Safari all shipped explicit blacklist entries so the certificate would not validate even if a user installed it.
That vendor response is worth noticing. The browser makers treated a government-mandated root CA as an attack, because structurally it is one. The only difference between "SSL inspection" and mass surveillance is who controls the root key and what they do with the plaintext.
How to tell whether your connection is intercepted
On a device you own but did not fully configure, such as a work laptop, checking takes under a minute:
- Inspect the certificate issuer. Click the padlock on any HTTPS site and view the certificate chain. If the root is your employer's name, or a security vendor's product name, rather than a public CA like Let's Encrypt or DigiCert, your traffic is being intercepted.
- Compare across networks. Load the same site on the corporate network and on your phone's mobile data. A different issuing CA on the corporate network is the tell.
- Watch for pinning failures. Applications that use certificate pinning refuse to accept the proxy's substitute certificate. If a specific app fails on the office network but works everywhere else, interception is the usual cause. Many enterprise proxies keep a bypass list for exactly these apps.
Note what does not help here: Certificate Transparency only covers certificates from public CAs, so a corporate root minting certificates locally never appears in any CT log.
What interception means for your actual privacy
On a managed device, assume the organization can read anything you do in a browser, including your personal webmail, your bank session, and any "private" browsing window. Private browsing prevents local history storage; it does nothing about a proxy that sees plaintext.
| What you use | What an intercepting proxy sees |
|---|---|
| Webmail over HTTPS | Full message contents, both directions |
| Banking session | Credentials and transactions, unless the app pins certificates |
| End-to-end encrypted messenger | Metadata and traffic patterns only; message contents stay encrypted because the keys never touch the proxy |
| VPN from the device | Often blocked or forced through the proxy; on managed devices the VPN itself is visible to the administrator |
The messenger row is the important one. End-to-end encryption is the one design that survives TLS interception, because TLS is only the outer layer. A proxy that terminates TLS on an end-to-end encrypted connection gets ciphertext it cannot decrypt, since the message keys live on the endpoints, not in the transport. That is precisely the property end-to-end encryption exists to provide: the network, including a hostile or nosy network, is not trusted.
The practical rules
Three habits cover most of the risk:
- Treat managed devices as observed. Do personal things on personal hardware, on a network you chose.
- Never install a root certificate someone hands you unless you accept that they can read all your TLS traffic from that point on. That is what the install means, whatever the stated reason.
- For anything that must stay private, use end-to-end encryption rather than relying on transport encryption, because you generally cannot verify who terminates TLS on someone else's network.
TLS interception is legal on hardware the interceptor owns, and in regulated industries it is sometimes mandatory. None of that changes the engineering fact: a connection is only as private as its least trustworthy endpoint, and interception quietly adds one you did not pick.
Originally published at havenmessenger.com
Top comments (0)