TLS Inspection Guide

Almost all web traffic is now encrypted, so a proxy or firewall that cannot see inside TLS sees little more than destinations, and an inspection system that is badly built weakens the very encryption it opens. TLS inspection (also called SSL inspection, TLS interception or break and inspect) is a deliberate, authorised man-in-the-middle that restores visibility for malware scanning, data loss prevention and policy enforcement, but it puts a certificate authority and a store of decrypted traffic in the middle of every user's session. This guide covers how interception works, when it is worth doing, TLS 1.3, Encrypted Client Hello and QUIC, certificate pinning and exemptions, upstream certificate validation, protecting the interception CA, privacy and employment law, performance and the alternatives. It is for network, security architecture and secure web gateway teams. Zero trust access design is covered in the ZTNA Guide and perimeter rule hygiene in the Firewall Management Guide.

Key takeaways

• Interception replaces the user's trust decision with yours. The browser can only verify the proxy, so the proxy must validate upstream certificates at least as strictly as a modern browser, or users lose protection they had before.
• The inspection CA is a high-value machine identity. Its private key can impersonate any website to every managed device; dedicate it, constrain it, keep it in hardware where possible and monitor what it issues.
• Inspect once, at one place. NSA advises breaking and inspecting TLS only once in an enterprise, with the outermost proxy making trust decisions.
• Exemptions are part of the design, not a failure. Pinned applications, mutual TLS, vendor-advised bypasses and privacy-sensitive categories such as health and banking need a documented bypass list.
• TLS 1.3 and ECH end passive tricks. Visibility now requires an active proxy or an endpoint control; plan for Encrypted Client Hello and QUIC rather than discovering them in your logs.

How TLS inspection works

CISA, summarising NSA's advisory, describes TLS inspection as "a security process that allows incoming traffic to be decrypted, inspected, and re-encrypted". In the common outbound case, a forward proxy sits between the client and the internet and runs two separate TLS sessions:

1. The client starts a TLS handshake to example.com. The proxy intercepts it (explicitly configured, transparently inline, or through an endpoint agent that steers traffic to a cloud gateway).
2. The proxy opens its own TLS session to the real server, receives the server's certificate chain and validates it.
3. The proxy generates a certificate for example.com on the fly, signed by an inspection CA that managed devices trust, and completes the client handshake with it.
4. Traffic is decrypted, passed to inspection engines (anti-malware, DLP, URL and application controls, sandboxing), then re-encrypted on the other leg.

Because there are two independent sessions, they can differ in protocol version, cipher suite and certificate quality. NSA's advisory (announced by CISA and reported in detail by SecurityWeek) warns that this TLS chaining can downgrade protection if the proxy accepts weaker settings than the client would.

Deciding whether, where and how much to inspect

The Dutch NCSC calls the TLS proxy "an attractive target" and asks organisations to make "a thorough assessment of the usefulness and necessity" of interception alongside other measures. Start from the threats you need to see, then pick the least intrusive control that sees them.

• Inspect once: NSA recommends breaking and inspecting TLS a single time, because one inspection is enough to detect threats and multiple layers obscure which device made the trust decision. If a cloud gateway decrypts, do not decrypt again at the on-premises firewall.
• Small organisations: a cloud SSE with endpoint agent and a short exemption list usually beats running a decrypting proxy you cannot staff. If you cannot monitor and maintain it, DNS filtering plus strong EDR may give more value for less risk. See the DNS Security Guide.
• Large organisations: centralise decryption policy in one place, assign an owner for the CA, and run inspection in a dedicated, isolated segment with separate administrative roles.
• Selective decryption: decrypting uncategorised, newly registered and high-risk categories, plus file downloads, gives most of the security value with less privacy exposure than decrypting everything.

TLS 1.3, Encrypted Client Hello and QUIC

• TLS 1.3 ends passive decryption: RFC 8446 (now obsoleted by RFC 9846, which still specifies TLS 1.3) states that "Static RSA and Diffie-Hellman cipher suites have been removed" and that "all public-key based key exchange mechanisms now provide forward secrecy". A device holding a server's private key can no longer decrypt recorded traffic. NIST's NCCoE notes this "may interfere with passive decryption techniques" and published SP 1800-37 on approaches for visibility inside enterprise environments.
• The certificate is no longer visible: in TLS 1.3 "All handshake messages after the ServerHello are now encrypted", so firewalls that categorised traffic from the server certificate must rely on SNI or decrypt.
• Encrypted Client Hello (ECH): RFC 9849 (March 2026) encrypts the inner ClientHello to a key published in DNS HTTPS records, hiding the SNI (the earlier ESNI draft was its predecessor), which it calls "perhaps the most sensitive information left unencrypted in TLS 1.3". The outer ClientHello shows only the provider's public_name, so SNI-based filtering sees, for example, the CDN rather than the site.
• What ECH means for proxies: a TLS-terminating proxy must "generate its own ClientHello containing only parameters it understands", so a full interception proxy still works. RFC 9849 notes that in managed enterprise settings one approach is to "disable ECH entirely via group policy", and that a proxy not authoritative for the public name "cannot forge a signal to disable ECH". Clients without an ECH configuration may also send GREASE ECH extensions, so the presence of the extension alone does not mean real ECH is in use.
• QUIC and HTTP/3: QUIC runs TLS 1.3 inside UDP 443, which TCP-based proxies cannot intercept. The common approach is to block UDP 443 outbound or disable QUIC by browser policy (Chrome's QuicAllowed), so browsers fall back to TCP.
• DNS is the other half: ECH keys come from DNS, so devices using external DNS over HTTPS escape both DNS filtering and your ECH policy. Enforce your own resolvers on managed devices.

Certificate pinning and the exemption list

Interception works only when the client trusts the inspection CA and accepts a substituted certificate. Many clients do not:

• Pinned applications: mobile apps, desktop update agents, some messaging and banking clients pin a certificate or public key and reject the proxy's certificate. They fail with connection errors, not certificate warnings.
• Clients with their own trust stores: Java (cacerts), Python (certifi), Node.js (bundled CAs, extended with NODE_EXTRA_CA_CERTS), Git, container images and Firefox (unless the ImportEnterpriseRoots policy is set) ignore the operating system store. Developers then disable verification to "fix" builds, which is far worse than an exemption.
• Mutual TLS: the proxy does not hold the client's private key, so client certificate authentication to a partner API or bank cannot survive interception. Exempt these destinations.
• Vendor bypass guidance: Microsoft, for example, advises customers to "Bypass Microsoft 365 domains from TLS decryption, traffic interception, deep packet inspection, and network packet and content filtering" for required endpoints, citing performance and the service's own security controls.

Keep the list in version control with an owner, reason and review date per entry. Exempt by category or exact domain, never by broad wildcard, and log exempted connections at domain level so the bypass is not a blind spot.

Validating upstream certificates properly

CERT/CC's Will Dormann put the core problem plainly: with interception, the client "can verify only that it is communicating with the SSL-inspecting software". He found products that failed to validate upstream certificates, validated but did not pass the result to the client, masked the real error, or sent the request upstream before warning the user. NSA adds that weak TLS versions and cipher suites must be disabled on both legs, with exceptions only for named legacy clients.

Dormann's practical method: visit badssl.com from a browser with direct internet access, repeat with the same browser behind the proxy, and compare. Any test site that loads only when intercepted "is an indication of a weakness introduced by HTTPS interception". Repeat after every proxy upgrade.

Where identity fits: protecting the interception CA

The inspection CA is a machine identity with more power than almost any other certificate you operate: managed devices will trust whatever it signs. NSA warns that attackers could use it to "sign malicious code and bypass host IDS/IPSs". Treat its private key like a tier 0 secret.

• Dedicate it: NSA recommends a CA used only for TLS inspection, configured to issue only TLS server authentication certificates, never a default or self-signed vendor certificate. Do not reuse your enterprise issuing CA.
• Constrain it: issue it with name constraints (NSA) so it cannot impersonate your own internal services, and an extended key usage limited to server authentication.
• Keep the key in hardware: generate the key in an HSM or on the appliance, sign a CSR with your offline root, and never export it. If a cloud provider holds the key, contract for how it is protected and how you revoke it.
• Distribute trust narrowly: push the CA only to managed devices through MDM or Group Policy, and remove it when a device leaves management.
• Plan rotation and revocation: document how to replace the CA on every device in a day if the key is suspected compromised.
• Separate duties: NSA recommends least privilege on decrypted data and an auditor role that can detect policy changes and admin abuse.

See the Machine Identity, PKI and Certificate Lifecycle Guide and the Cryptographic Key Management Guide.

Privacy and legal considerations

Decrypted traffic contains personal data, often special category data. NSA reminds operators that TLS inspection is subject to privacy laws, and the Dutch NCSC asks for a compliance review covering at least the processing of personal data. In the UK, the ICO's guidance on monitoring workers (under review following the Data (Use and Access) Act) says employers must identify a lawful basis, "must inform workers about any monitoring", select "the least intrusive means", and carry out a DPIA before processing likely to result in high risk. It warns that monitoring can capture special category data incidentally, such as emails with a healthcare provider. See the DPIA Guide: Running a Data Protection Impact Assessment.

• Tell people: publish an acceptable use and monitoring notice that says traffic is decrypted, what is exempt, what is logged and who can see it.
• Consult early: works councils or employee representatives must be consulted in some countries before monitoring starts.
• Minimise retention: store verdicts and metadata, not decrypted content, unless a specific investigation requires it.

Rolling out TLS inspection

1. Prepare: complete the DPIA and notices, define the exemption list, and build the dedicated inspection CA under your PKI.
2. Distribute trust: deploy the CA to managed device trust stores, Firefox enterprise roots and developer tooling (Java, Python, Node.js, container base images) before turning anything on.
3. Validate the proxy: run the badssl.com comparison and upstream certificate tests in a lab.
4. Pilot ring: enable decryption for IT and security staff, in log-only mode where the product allows, for two to four weeks. Record every breakage and decide exempt, fix trust store or accept.
5. Expand by category: start with high-risk and uncategorised traffic, then broaden. Block QUIC and set the ECH browser policy at the same time.
6. Roll back: keep a single policy switch that returns a group to no-decrypt (traffic still passes, filtered by domain) and test it during the pilot.

Performance and resilience

• Size on decrypted throughput: datasheets usually quote a separate, much lower figure with decryption and threat prevention enabled; plan on that number and new-session rate, not headline firewall throughput.
• Decide fail-open or fail-closed per traffic class when the inspection engine is overloaded or unavailable, and alert on either.
• Contain decrypted traffic: NSA recommends keeping it within an isolated network segment so it cannot be misrouted to weakly protected networks.
• Watch latency for real-time apps: voice, video and collaboration traffic are frequent bypass candidates for performance as well as supportability.

Detection and measurement

Log decryption decisions (decrypted, exempted and why, failed), upstream certificate errors, certificates issued by the inspection CA, and administrative changes to decryption policy and exemption lists. Alert on any certificate chaining to the inspection CA observed outside the proxy, on new exemptions without a ticket, and on endpoints with verification disabled in tooling.

• Decryption coverage: share of outbound TLS sessions decrypted, against the share intended by policy.
• Undecryptable traffic: volume of QUIC, ECH and handshake failures, trending down after policy changes.
• Exemption hygiene: number of exemptions, percentage with an owner and in-date review.
• Validation pass rate: badssl.com and upstream certificate tests passed after each upgrade (target 100%).
• Detection yield: malware, DLP and C2 detections that required decryption, to justify the cost.
• User impact: helpdesk tickets attributed to inspection per thousand users.

Common failure patterns

• Vendor default CA left in place: a certificate shared across customers, or a key exportable from the console.
• Re-signing invalid certificates: the proxy turns an expired or spoofed upstream certificate into a trusted one, so users never see the warning they would have seen without inspection.
• Double decryption: cloud gateway and on-premises firewall both intercept, producing chained certificates no one can troubleshoot.
• Developers disabling verification: verify=False or NODE_TLS_REJECT_UNAUTHORIZED=0 in scripts and pipelines because the inspection CA was not distributed to tooling.
• Wildcard exemptions: broad bypasses added to fix one broken app that open a large blind spot.
• QUIC left open: a growing share of browser traffic passes uninspected over UDP 443.

Framework mapping

Practitioner checklist

• Document why you inspect, what you inspect and what you exempt, and complete a DPIA before go-live.
• Use a dedicated, name-constrained inspection CA limited to server authentication, with its key in hardware.
• Decrypt in one place only and keep decrypted traffic in an isolated segment.
• Verify the proxy blocks invalid upstream certificates using the badssl.com comparison after every upgrade.
• Disable weak TLS versions and ciphers on both legs, with named legacy exceptions only.
• Maintain an owned, reviewed exemption list for pinned, mTLS, health, banking and vendor-advised destinations.
• Distribute the CA to developer tooling and ban verification-disabling settings.
• Block QUIC and set ECH and DNS policy on managed browsers and devices.
• Separate proxy administration from audit, and alert on decryption policy changes.

Standards and references

• CISA: NSA Releases Cyber Advisory: Managing Risk from Transport Layer Security Inspection
• IETF: RFC 9849 TLS Encrypted Client Hello
• IETF: RFC 9846 The Transport Layer Security (TLS) Protocol Version 1.3
• NIST NCCoE: Addressing Visibility Challenges with TLS 1.3 (SP 1800-37)
• NCSC Netherlands: Factsheet TLS interception
• CERT/CC (SEI): The Risks of SSL Inspection
• ICO: Data protection and monitoring workers

Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Cryptographic Key Management Guide · ZTNA Guide · Firewall Management Guide · Email Security Guide. This guide summarises privacy and employment monitoring considerations and is not legal advice.