TLS Decryption on Secure Firewall: Worth It?

By Taylor Thomas · 2026-09-01

Most traffic crossing an enterprise edge today is encrypted, and an inspection engine cannot match content it cannot read. That is the entire case for TLS decryption on Cisco Secure Firewall: intrusion inspection, file policy, and content-dependent application detail all work best on cleartext, and a decryption policy is how they get it. The case against is equally concrete — decryption costs throughput, breaks a predictable class of applications, and carries privacy obligations. Deciding where decryption is worth it, flow by flow, is the actual engineering task.

What You Cannot See Without It

An undecrypted TLS connection still shows the firewall its unencrypted metadata: addresses and ports, the server name most clients today still offer in the clear — Encrypted Client Hello, where used, conceals it — and — in a full certificate-based TLS 1.2 handshake — the server certificate itself. TLS 1.3 moved the server certificate into the encrypted portion of the handshake, so even that is no longer visible to a passive middlebox. What never crosses in the clear is the payload. Intrusion rules that match exploit content, file policies that extract and analyze transferred files, and application inspection that depends on message content simply cannot evaluate an encrypted payload. Whatever your access control policy says, on encrypted traffic its content-dependent conditions are working blind.

The Two Decryption Modes

Secure Firewall decrypts in two fundamentally different ways, and the difference is who owns the server.

For outbound traffic to servers you do not control, the mode is Decrypt-Resign. The firewall sits in the middle of the TLS exchange: it negotiates one session with the client and another with the server, decrypting and re-encrypting in between. The client cannot receive the server’s real certificate — the firewall is impersonating the server — so the firewall presents a substitute, re-signed by a CA whose certificate and private key it holds. Every client that will have its traffic decrypted must trust the resulting chain — in practice an internal CA distributed to managed endpoints, or a subordinate CA issued from one they already trust. Skip that step and decrypted sessions fail certificate validation: browser warnings users learn to click through at best, silent connection failures for stricter clients.

For inbound traffic to servers you do control, the mode is Decrypt-Known-Key. The firewall holds the server’s own certificate and private key, so it can stand in the TLS exchange as the server itself would — no substitute certificate is involved, and clients see the genuine one. The cost is key handling: the server’s private key now also lives on the firewall and must be protected and rotated accordingly.

What Breaks, and What It Costs

Resign-based decryption fails against clients that refuse substitute certificates. Certificate and key pinning do exactly that by design, and mutual TLS fails for a structural reason — the firewall cannot prove possession of the client’s private key, so client authentication cannot complete through resign-based interception (under Do Not Decrypt it passes end to end untouched). For such traffic you intend to permit anyway, the operational answer is exemption: identify it and carry it in Do Not Decrypt rules rather than fighting it — while traffic you would rather refuse than pass uninspected is a legitimate candidate for blocking instead. Privacy-sensitive categories — health, finance, personal banking — commonly join the exemption list on privacy policy, risk assessment, and legal advice rather than technical necessity.

Then there is the performance bill. TLS termination is cryptographic work on every decrypted flow — the firewall is running the handshake and record encryption for two sessions per connection — and platforms rate throughput with TLS inspection enabled below their cleartext figures. Decrypting everything is rarely a defensible design; decrypting the categories where payload inspection changes outcomes — unclassified web traffic, file-transfer paths, high-risk destinations — usually is.

Deciding, and Inspecting Without Decrypting

A useful discipline is to write down, per traffic class, which inspection you actually need. Where file and intrusion inspection matter, decrypt and accept the cost. Where they cannot work anyway — pinned applications, mutual TLS — exempt. Where policy forbids decryption, lean on what encrypted traffic still reveals: the access control policy can still act on packet-one conditions, and the Encrypted Visibility Engine draws inferences about the client software behind a connection from handshake characteristics without decrypting anything. That is visibility, not payload inspection — it informs policy, it does not replace file analysis.

On the certification map, this sits squarely in the SNCF 300-710 orbit: objective 2.2 covers configuring Secure Firewall policies, and 2.3.d names the Encrypted Visibility Engine specifically. The SNCF course works both sides — building decryption policy on real FTD, and reading what encrypted flows reveal when decryption is off the table. For the wider policy architecture the decryption decision lives inside, start with the course catalog.

Frequently Asked Questions

What is the difference between Decrypt-Resign and Decrypt-Known-Key?

Decrypt-Resign is for outbound traffic to servers you do not control: the firewall terminates the client's TLS session, builds its own session to the server, and presents the client a substitute certificate re-signed by a CA whose certificate and signing key the firewall holds — a chain your endpoints must trust. Decrypt-Known-Key is for inbound traffic to servers you do control: the firewall holds the real server certificate and private key, so no substitution is involved and clients see the genuine certificate.

Why does TLS decryption break some applications?

Resign-based decryption works by substituting the server certificate, and some clients refuse any substitute. Applications that pin a specific certificate or public key reject the re-signed copy, and mutual TLS fails because the firewall cannot prove possession of the client's private key to the server, so client authentication cannot complete through it. For traffic that must remain permitted, the fix is not to force decryption but to identify it and exempt it with a Do Not Decrypt rule.

Can a firewall detect threats in encrypted traffic without decrypting it?

Partially. Unencrypted handshake metadata and traffic characteristics still leak useful signal, and Cisco Secure Firewall's Encrypted Visibility Engine uses that signal to draw inferences about the client software behind a connection without decrypting anything. That supports visibility and policy decisions, but it is not equivalent to payload inspection: file inspection and content-based intrusion rules still require a cleartext view.