What is TLS inspection?
TLS inspection, also called SSL inspection, HTTPS inspection or TLS interception, is the practice of decrypting encrypted traffic at a security device so its content can be checked. Because nearly every website now uses TLS, a security device that cannot decrypt is limited to metadata: addresses, ports, the hostname in the Server Name Indication (SNI) field and, under TLS 1.2 but not TLS 1.3, the server's certificate. Metadata supports blocking by site category. It does not let antivirus examine a downloaded file, let IPS signatures match an exploit inside the session or let DLP read a document on its way out.
How TLS inspection works
For outbound traffic, the inspecting device places itself between the user and the site and runs two separate TLS sessions:
- The client starts a TLS connection to a site, and the proxy or firewall intercepts it.
- The device connects separately to the genuine server over TLS and validates that server's certificate.
- It creates a certificate for the requested hostname, issued on the spot by an internal certificate authority (CA), and completes the handshake with the client.
- The client accepts that certificate because the internal root CA was pushed to the trust store of every managed device, for example through Group Policy or MDM.
- The device decrypts the traffic, runs malware scanning, DLP, IPS and URL checks, then re-encrypts it toward the other side.
Inbound inspection of the organization's own servers works differently. A load balancer, WAF or reverse proxy holds the servers' real certificates and private keys and terminates TLS before inspecting. Because TLS 1.3 removed RSA key exchange and uses ephemeral keys, a passive sensor cannot decrypt a copy of the traffic just by holding the server's key; the device must terminate the session.
Example: checking whether traffic is inspected
On a managed laptop, examining the certificate a site presents shows who signed it:
openssl s_client -connect www.example.com:443 -servername www.example.com
If the issuer line names the company's own inspection CA instead of a public CA, the connection is being inspected. A device that is missing the internal root shows certificate errors on every HTTPS site, such as NET::ERR_CERT_AUTHORITY_INVALID in Chrome. That is the classic symptom after a new inspection proxy goes live before the root certificate has reached every device.
Trade-offs and exemptions
- Employee privacy: most deployments skip decryption for categories such as online banking and health sites, and the acceptable use policy tells staff that other traffic may be decrypted. Privacy law in some countries restricts the practice further.
- Apps that refuse the swap: software that pins a specific certificate, or that requires mutual TLS, fails when it is handed the proxy's certificate, so those destinations are excluded from decryption.
- A high-value target: one device now holds plaintext for the whole company, and anyone who steals the inspection CA's private key can forge certificates that managed devices trust. Store that key in an HSM where possible.
- Certificate checking moves to the device: users see the proxy's certificate, not the site's, so the proxy itself has to refuse expired, mismatched or untrusted server certificates.
- Blind spots: Encrypted Client Hello can hide the hostname, and QUIC (HTTP/3 over UDP 443) slips past many TCP proxies, so organizations often block QUIC to make browsers fall back to TLS over TCP.
- Capacity: decrypting and re-encrypting every session costs significant processing power, which has to be planned for.
TLS inspection vs. an on-path attack
Technically, TLS inspection is an on-path (man-in-the-middle) position. The difference is authorization: the organization owns the devices, controls the trust store and tells users. Attackers and adware use the same technique without permission. In 2015, Superfish adware preinstalled on some Lenovo consumer laptops added a root certificate whose private key was the same on every machine, so anyone who extracted that key could intercept those users' HTTPS traffic. An unexpected root certificate in a trust store deserves investigation.
TLS inspection on the CompTIA Security+ exam
TLS inspection is taught with content filtering, proxies and DLP under SY0-801 objective 4.1, which covers mitigating controls. Wording such as encrypted uploads are invisible to DLP or the IPS cannot inspect encrypted traffic points to TLS inspection. Some laptops show a certificate warning on every HTTPS site since the proxy went live points to the internal root CA missing from those devices, and one banking app fails after inspection was enabled points to certificate pinning and a bypass rule. Distractors include disabling TLS, downgrading to HTTP, adding a WAF, which protects inbound web applications, and buying a new public certificate, which does nothing for outbound inspection.