TLS inspection is a security technique in which a firewall, secure web gateway or similar device decrypts traffic protected by Transport Layer Security (TLS), examines the content for threats or policy violations, then re-encrypts it and sends it on. Because much of today’s web and application traffic is encrypted, security tools that can’t see inside it miss much of what passes through. For each connection it inspects, the device effectively sits in the middle, with the organization’s permission and a certificate authority its devices trust.
At a glance
- TLS inspection lets security tools examine encrypted traffic that would otherwise be hidden from them.
- It is a feature of next-generation firewalls, secure web gateways, security service edge platforms and some other security products.
- For outbound web traffic, company devices must trust the inspection system’s certificate authority (CA), set up by the organization or the inspection service.
- Decryption takes significant processing power and can break some applications.
- Many organizations exclude sensitive categories, such as banking and health sites, for privacy and legal reasons.
What problem it solves
Transport Layer Security (TLS) protects traffic from eavesdroppers, which is good for privacy and security. But attackers use encryption too: malware is downloaded over HTTPS, phishing sites have valid certificates, and stolen data can be uploaded to cloud storage over encrypted connections. A security device that only sees encrypted traffic can identify where it is going, but not what it contains.
TLS inspection restores that visibility. Once decrypted, traffic can be checked by antivirus scanning, intrusion prevention, data loss prevention (DLP) and content filtering, the same way unencrypted traffic used to be. Without it, those features can’t see the content of encrypted connections, which now carry much of web traffic.
How it works
Trusted certificate authority. The organization installs the inspection certificate authority’s (CA’s) certificate in the trust stores of managed devices, usually through device management. The CA may be the organization’s own or one provided by the inspection service. The inspection system holds the matching CA private key, which is highly sensitive: anyone who obtains it could create certificates those devices would trust, so it needs strong protection and limited access. This relies on public key infrastructure (PKI) concepts.
Intercepting the connection. When a user connects to a website, the inspection device creates two encrypted connections: one with the user’s device, using a certificate it generates for that site and signs with the CA private key, and one with the real website.
Inspection. In between, traffic is decrypted and passed to security features, such as deep packet inspection (DPI) based threat prevention, malware scanning, DLP and URL filtering.
Re-encryption. Allowed traffic is re-encrypted and forwarded. Blocked traffic is dropped or the user sees a block page.
Policy and exclusions. Administrators choose which categories, applications and users to decrypt, and maintain exclusions for privacy-sensitive categories and applications that break.
Inbound inspection. A related mode decrypts traffic coming into the organization’s own servers, using those servers’ certificates, so threats aimed at them can be inspected.
When it matters for buyers
- When choosing a firewall or secure web gateway. Throughput with decryption turned on is often much lower than the headline figure; size for the traffic you will decrypt. Our secure web gateway overview covers how cloud and on-premises options compare.
- When moving inspection to the cloud. Cloud security platforms take on the processing load but still need certificates deployed to devices.
- When DLP or threat prevention seems to miss things. Undecrypted traffic is a common reason.
- When privacy, works councils or regulation are factors. Policy, notice and exclusions may be required, depending on where staff are located.
- When certificate pinning or newer protocols are in use. Some traffic can’t be inspected without breaking it, and some products handle newer protocols better than others.
Questions to ask vendors
- What is the throughput with TLS inspection enabled, at our expected traffic mix and with the other security features we will use?
- Which TLS versions and newer web protocols do you support for inspection?
- How do you handle applications that break, and how is the exception list maintained?
- How is the inspection CA certificate deployed to managed and unmanaged devices, and how is the CA private key protected?
- Can we exclude categories such as finance and health easily, and log what was and wasn’t inspected?
- Is decrypted content stored anywhere, and who can access it?
How it differs from TLS itself
TLS is the encryption protocol that protects traffic between two parties. TLS inspection is a security practice that deliberately, and with the organization’s authorization, opens that protection in the middle so the traffic can be checked, then re-applies it. The network firewalls or gateways doing the inspection become a trusted point that holds decrypted traffic briefly, which is why securing and auditing them matters.