SSL Decryption Depth vs Stability on Web Security Appliances
Halcyon Logistics runs Forcepoint Web Security on a pair of V-Series appliances in its data centre, serving 5,000 users over a 1 Gbps internet link. Selective SSL decryption was recently widened from suspicious and uncategorised destinations to every category except Health and Finance. Within a week the service desk logs 380 tickets: Microsoft Teams calls drop, the OneDrive sync client reports certificate errors, a vendor updater fails, and an in-house fare-quoting application that pins its certificate cannot connect at all. Mean page latency rose by 45 ms, appliance CPU sits at 86 percent at peak, and concurrent TLS sessions are 30 percent above the sizing estimate. Management wants to keep inspection depth for data-loss purposes but cannot accept this outage pattern. The in-house application's domains sit in a custom URL category that also contains several SaaS tools used by every department, so a category-level bypass is too broad.
1. Why do the pinned and certificate-validating applications fail, and how do you restore them without a category-wide decryption bypass?
Read the worked answer
Decryption is interception: the appliance terminates TLS, re-signs the connection with a certificate from the enterprise CA, and opens its own session upstream. Applications that pin a certificate or public key compare what they receive against a value baked into the client, so the substitution fails regardless of whether the enterprise CA is trusted by the operating system. The OneDrive and Teams symptoms are the same mechanism plus strict transport validation.
The fix is precise, not category-wide:
- Split the custom category. Create a narrow category containing only the fare-quoting hosts and the vendor endpoints, and exclude it from decryption. Leave the mixed SaaS category inspected so data-loss visibility is preserved.
- Enumerate domains from vendor documentation. Pinned apps often use several hostnames and CDN endpoints; a partial exclusion list produces intermittent failures that look like random outages.
- Use published exclusion lists. Major SaaS providers publish endpoints that should not be inspected. Apply them as a managed list with a review date rather than ad hoc edits.
Accept the consequence: excluded traffic is invisible to content inspection, so cover the same data through API-based cloud app monitoring and endpoint DLP instead of pretending the web control still applies. Record the exception with an owner and a reason, since every exclusion is a documented blind spot.
2. CPU is at 86 percent at peak and latency rose 45 ms. Explain the capacity reasoning and the changes you would make to decryption scope and platform, including what happens on failover.
Read the worked answer
An HA pair at 86 percent peak is already out of headroom. On failover one appliance carries the full load, which means the surviving node is over capacity and users see timeouts rather than degradation - a worse failure mode than the current one. Size for N+1, so each node must handle peak alone at a sustainable level.
Reduce the work per connection. Decryption cost is per handshake plus per byte scanned. Restrict decryption to categories that carry data-loss risk: personal storage, file transfer, uncategorised, newly registered domains, webmail. Exclude streaming media, software update and operating-system telemetry categories, which are high volume and low risk. Confirm session reuse, HTTP/2 support and any available crypto offload are enabled, and check whether the TLS profile forces expensive ciphers.
Reduce the number of users inspected. Consider decrypting for roles that handle regulated data and leaving general browsing inspected only for threats. That lowers load and shrinks the privacy footprint, which the works council will raise.
Add capacity where the traffic is. The 45 ms is consistent with added round trips and queueing. Measure with decryption off for a control group before buying hardware. If the branch traffic dominates, a cloud-delivered web security service may be cheaper than upgrading the data-centre pair.
Set an operational threshold: sustained CPU above 70 percent at peak triggers a review, and record the failover capacity test as evidence.