How SSL decryption on a firewall works, and what not to decrypt

SSL decryption on a firewall means the firewall runs two separate TLS sessions, one with the client and one with the server, and reads the traffic in plaintext between them before encrypting it again and passing it on. The names differ by vendor. Palo Alto Networks calls it SSL Forward Proxy and SSL Inbound Inspection; Fortinet calls it deep inspection or full SSL inspection; Cisco Secure Firewall uses the rule actions Decrypt - Resign and Decrypt - Known Key. Underneath, the mechanism is the same.

Below is the mechanism step by step, then the two lists that slow most decryption projects down: traffic that can't be decrypted, and traffic that shouldn't be. If the TLS 1.3 handshake messages aren't familiar, read TLS 1.3 handshake, message by message first. I won't repeat the handshake here.

 CLIENT                     FIREWALL                  SERVER    
┌──────────┐             ┌────────────┐             ┌──────────┐
│ laptop   │   TLS #1    │          ● │   TLS #2    │ server   │
│          │●────────────│ decrypt    │─────────────│          │
│ trust:FW │             │ inspect    │             │ real cert│
└──────────┘             │ re-encrypt │             └──────────┘
                         │            │                         
                         └────────────┘                         
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
 1  ClientHello to files.example.com, intercepted               
                                                                
 two TLS sessions; plaintext exists only inside the firewall    

Why does a firewall have to decrypt traffic to inspect it?

Because what the security profiles need to see (the full URL, the downloaded file, an exploit in the payload) is all inside the encrypted part. Palo Alto Networks' Decryption Basics page says it directly: you can't block traffic that you don't inspect. Its example is malware placed on an HTTPS site that employees then download without knowing.

Fortinet's Deep inspection page gives similar cases: a virus picked up during an e-commerce session, or a phishing attachment that opens an encrypted session to a command-and-control server. Because those sessions are encrypted, they might get past your network's security measures.

How does forward proxy decryption work, step by step?

Forward proxy handles traffic from internal users out to the internet. The firewall creates two separate sessions: one between the client and the NGFW, and the other between the NGFW and the server. The sequence in Palo Alto Networks' SSL Forward Proxy documentation:

Step 1: the client starts a TLS session

A client inside the network opens a TLS session to an external server, say https://files.example.com. The firewall intercepts it. To the client, the firewall is now the server.

Step 2: the firewall opens its own session to the real server

The firewall connects to the server as a client. The server sees no middlebox and returns its certificate.

Step 3: the firewall checks the server's certificate

If the server certificate is signed by a CA the firewall trusts, the firewall generates an SSL Forward Trust copy of the server certificate and sends it to the client. If not, it sends a copy signed with the Forward Untrust certificate, and the client shows a warning. Either copy is called an impersonation certificate, because it isn't the server's real one.

Step 4: the client checks what it received

The client validates the impersonation certificate as usual. Two key exchanges follow: client to firewall, firewall to server.

Step 5: traffic flows through the firewall

The firewall decrypts the SSL traffic, applies Security policy rules and security profiles and decryption profiles to the traffic, reencrypts the traffic, and then forwards it, in both directions.

Fortinet describes the same thing: the FortiGate acts as a subordinate CA to sign the certificate on the fly as it re-encrypts, usually with a subordinate CA signed by the company's private CA. On Cisco, Decrypt - Resign is the action for outbound traffic; the system re-signs the server certificate with the CA certificate, then acts as a man-in-the-middle.

Why do clients have to trust the firewall's CA?

Because the certificate the client receives in step 3 is signed by the firewall, not a public CA. Without that CA in the client's trust store, every site shows a warning. Palo Alto Networks: if you don't install the Forward Trust certificate on client systems, users see certificate warnings for each SSL site they visit. Fortinet states the same requirement: there must be a certificate chain back to the trusted root CA that is installed on the user's endpoint.

There are two ways to get there (Palo Alto Networks):

• A certificate signed by your enterprise CA, which managed devices already trust. Nothing extra to distribute.
• A self-signed certificate, whose root you export and add to the clients' Trusted Root Certification Authorities store.

Two points in the same documentation are worth underlining. The Forward Trust private key should remain on the NGFW and not be exported to client systems. And don't install the Forward Untrust certificate on client systems: its whole job is to make the client warn about servers with untrusted certificates, and a client that trusts it stops warning.

The Forward Trust CA key can sign a certificate for any domain, and every managed client will accept it. That's why Palo Alto Networks suggests storing that private key on an HSM and backing it up somewhere secure.

How is inbound inspection different from forward proxy?

Inbound inspection covers traffic from outside to your own servers, and the firewall uses each server's real certificate and private key instead of signing new ones. SSL Inbound Inspection requires installation of the certificate and private key of each internal server you want to protect. The firewall checks that the certificate the server sends matches one in the decryption policy rule, and only then passes it to the client.

Cisco's equivalent, Decrypt - Known Key, is best suited to decrypt traffic incoming to servers your organization controls, and you need the server's private key.

What can a firewall still see without decrypting?

Whatever comes before the encrypted part. FortiGate's certificate inspection profile only inspects the headers up to the SSL/TLS layer, and Fortinet suggests it for cases where you do not want to deep scan for privacy reasons but you want to control web site access. The built-in profile listens only on port 443; a site on 8443 needs a custom profile.

The catch is that TLS 1.3 encrypts the server certificate, so there's less left to look at. Which handshake fields stay readable is covered in TLS 1.3 handshake, message by message.

Which traffic can't be decrypted?

Pinned certificates, client-certificate authentication, and anything not running over ordinary TLS. Because the firewall is a proxy, it can't decrypt certain sessions, such as those with client authentication or pinned certificates.

• Certificate pinning. The app accepts only a certificate it already knows, so the impersonation certificate fails. Cisco: you cannot decrypt this traffic by re-signing the server certificate. There is no workaround, and Cisco recommends a Do Not Decrypt rule above the Decrypt - Resign rule.
• Mutual authentication. The server asks for a client certificate. The firewall doesn't hold the client's private key, so it can't present that certificate on the client's behalf.
• Incomplete certificate chains and unsupported ciphers. Palo Alto Networks lists both as technical reasons for exclusion.
• QUIC. It runs over UDP and cannot be decrypted. The documented approach is to block it, which forces browsers back to TLS.

PAN-OS keeps this traffic in three places: the predefined exclusion list, which Palo Alto Networks maintains through content updates; the Local SSL Decryption Exclusion Cache, where the firewall automatically excludes sites for 12 hours if the profile allows unsupported modes; and your own custom exclusion list.

Which traffic shouldn't be decrypted?

Traffic you could decrypt but shouldn't, because of law, company policy or user privacy. The category all three vendors name is finance and health:

• Fortinet: in a full SSL inspection profile, the Finance and Banking, Health and Wellness, and Personal Privacy categories are exempt from inspection by default.
• Palo Alto Networks: traffic you choose not to decrypt because of business, regulatory, personal, or other reasons, such as financial-services, health-and-medicine, or government traffic belongs in a policy-based decryption exclusion.
• Cisco: don't decrypt if doing so is forbidden by law, company policy, or privacy regulations.

On PAN-OS the two groups live in different places: technical breakage in an exclusion list, deliberate choices in no-decrypt rules matched on URL category, source or destination. Kept apart, you can still tell later why each entry exists.

Fortinet adds a point I agree with: users should be made aware that their communication is subject to these security measures and that their privacy can't be guaranteed. Palo Alto Networks warns that the use of SSL traffic is regulated in some countries and jurisdictions, so check local law before mirroring or storing decrypted traffic. For your own jurisdiction, ask your legal team.

What does TLS 1.3 change for decryption?

Without decryption the firewall can no longer see the certificate, and inbound inspection can't rely on RSA key exchange any more. Palo Alto Networks' TLS 1.3 Decryption page lists the effects on configuration (Palo Alto Networks):

• It's opt-in. Without TLSv1.3 in the decryption profile, PAN-OS uses TLSv1.2 as the maximum. The recommendation is Min Version TLSv1.2 and Max Version "Max".
• Pinned mobile apps. TLS 1.3 encrypts certificate information that was not encrypted in previous TLS versions, so the firewall can't add automatic exclusions from certificate data and may drop some mobile app traffic. Cap those rules at TLSv1.2, or give the apps a separate No Decryption rule.
• No Decryption profiles stop working. They check for expired certificates and untrusted issuers, but with TLS 1.3 the firewall can't see the certificate, which makes the profile ineffective.
• Inbound inspection. TLSv1.3 removes support for the RSA key exchange algorithm, and in a TLS 1.3 handshake the firewall sends the client the same certificate or chain it received from the server.

Cisco has its own limit: with TLS 1.3 decryption enabled, an ECDSA certificate on a Decrypt - Known Key rule means matching traffic will be blocked.

What new risks does decryption add?

The firewall becomes the only thing checking the server's certificate on the client's behalf, and if it checks badly, the client can't tell. CISA Alert TA17-075A explains that the client can only verify the connection between itself and the HTTPS interception product and has to rely on the product's validation. The same alert cites research finding that many products do not properly verify the certificate chain of the server before re-encrypting and forwarding client data, and some accept old protocol versions or weak ciphers towards the server while the client side looks strong.

CISA's suggested test is badssl.com: at a minimum, any Certificate test that stops a directly connected client should also stop a client going through the interception product (TA17-075A).

Other risks in the vendor documentation:

• Decryption port mirroring forwards decrypted traffic in cleartext, including sensitive information.
• HA. PAN-OS doesn't support HA sync for decrypted SSL sessions; after a failover, decrypted sessions don't resume.

Where do you start with a decryption policy?

Write the rules that don't decrypt first, then turn decryption on one group at a time. Each item below comes from the documents cited above; the order is my opinion.

1. Pick the CA. A subordinate CA from your enterprise CA if you have one, the key on an HSM if possible, the root pushed to clients through device management.
2. Write no-decrypt rules by URL category for finance, health and anything legal names. Place them above the decrypt rules.
3. Block QUIC for traffic you intend to decrypt, so browsers use TLS.
4. Set the decryption profile: Min TLSv1.2, Max "Max", plus a separate rule and profile capped at TLSv1.2 for pinned mobile apps.
5. Decrypt a pilot group first and read the decryption logs: which sessions fail, and why.
6. Add exclusions only where needed. Palo Alto Networks: don't make decryption exceptions unless you must.
7. Run badssl.com through the firewall and compare with a direct connection.

As a PAN-OS rule table, step 2 looks roughly like this (rule and zone names are examples):

#  name                  from   to       url-category                               action
1  no-decrypt-sensitive  trust  untrust  financial-services, health-and-medicine    no-decrypt
2  no-decrypt-pinned     trust  untrust  (custom list of pinned apps)               no-decrypt
3  decrypt-outbound      trust  untrust  any                                        ssl-forward-proxy

Rules are evaluated top-down, so the no-decrypt rules go first. Cisco recommends the same for pinned traffic: a Do Not Decrypt rule ordered before Decrypt - Resign rules.

Sources

• Palo Alto Networks: Decryption Basics
• Palo Alto Networks: SSL Forward Proxy
• Palo Alto Networks: SSL Inbound Inspection
• Palo Alto Networks: Keys and Certificates for Decryption Policies
• Palo Alto Networks: Configure SSL Forward Proxy
• Palo Alto Networks: Decryption Exclusions
• Palo Alto Networks: TLS 1.3 Decryption
• Fortinet: SSL/TLS deep inspection (FortiOS 7.4 Best Practices)
• Fortinet: Deep inspection (FortiOS 7.4.3)
• Fortinet: Certificate inspection (FortiOS 7.4.3)
• Cisco: Secure Firewall Management Center Device Configuration Guide 7.4, Decryption Rules
• CISA Alert TA17-075A: HTTPS Interception Weakens TLS Security