A recurring point of contention in our internal performance benchmarking for NGFW deployments, specifically with Cisco Firepower Threat Defense (FTD) running on the 2100/4100 series appliances, is the handling of encrypted SaaS application traffic. The historical approach of deploying a decryption policy with a full TLS proxy for domains like `*.salesforce.com` or `*.office365.com` is increasingly problematic, both from a performance overhead and an end-user privacy/experience standpoint.
I've conducted a series of controlled tests to quantify the impact. Using a reproducible synthetic workload designed to simulate a mix of SaaS application transactions (API calls, document sync, web portal interaction) over TLS 1.2/1.3, the results on an FTD 4112 with decryption enabled were as follows:
* **Median Latency Increase:** 142ms → 211ms (+48.6%)
* **CPU Utilization (SSD):** 34% → 67% (near-linear scaling with session count)
* **Maximum Sustained Sessions (with decryption):** ~58% of the rated capacity without decryption.
The configuration snippet for the decryption policy used in this test was straightforward:
```bash
crypto ca trustpoint SALESFORCE-CA
enrollment terminal
fqdn salesforce.com
subject-name CN=Salesforce.com CA
revocation-check none
!
decrypt-policy SaaS_Decrypt
match source-ip 10.0.0.0/8 destination-fqdn salesforce.com
action decrypt
```
The performance tax is clear. Furthermore, many modern SaaS applications employ techniques like certificate pinning or use of non-standard ports, which can break decryption and cause user-visible failures.
My question to the community is methodological: **What is now considered the best-practice, reproducible configuration for handling SaaS app decryption on Firepower, balancing visibility, performance, and user privacy?**
I am particularly interested in concrete, testable approaches. For example:
* **Selective Decryption:** Are you using URL-based filters to decrypt only specific subpaths (e.g., `*.sharepoint.com/*/upload*`) while leaving broad categories exempt?
* **TLS 1.3 & DoH:** How are you adapting decryption policies for TLS 1.3's more complex handshake and the rise of DNS-over-HTTPS, which obscures the initial destination lookup?
* **Performance Tuning:** Have you found specific hardware modules (like the M5 for 4100 series) or software tweaks (`ssl-proxy` settings, session timeouts) that materially improve the throughput/latency metrics in a benchmark?
* **Exclusion Lists:** What is your empirically derived list of SaaS categories or specific domains (e.g., `login.microsoftonline.com`) that must be excluded from decryption to maintain application functionality?
I plan to run a new round of benchmarks incorporating the most cited strategies. The goal is to produce a comparative analysis of throughput, latency distributions (p95, p99), and session establishment rates under each policy configuration. Share your detailed config examples and any internal benchmark data you can disclose.
-- bb42
-- bb42