HTTPS Inspection vs. the Business
Tailspin Health has 6,000 users on an R81.20 cluster with HTTPS Inspection and Threat Prevention enabled. Two profiles exist: Recommended applied to everyone, and Strict applied to the 300 users in finance. Since the last jumbo hotfix, four issues are open. The CRM SaaS application fails to load in the browser for all users, while Outlook and Teams work normally. Appliance CPU reaches 90-95% between 09:00 and 10:30. A Cloudflare-fronted supplier portal is never inspected and the log only shows "Bypass". An internally signed administration tool used to patch 400 servers is blocked as Trojan.Win32.Generic, stopping the rollout. Finance also complains that every invoice PDF they receive arrives as a stripped-down replacement, with the original available only as a link. The CISO has stated that HTTPS Inspection must not be switched off and that the patch must complete this week.
1. How would you troubleshoot the CRM failure without disabling HTTPS Inspection on the cluster?
Read the worked answer
Work the log first, in this order.
- Filter SmartLog on the CRM destination and add the HTTPS Inspection blade columns: HTTPS Inspection, Bypass Reason, and Certificate. A bypass reason of "Unsupported category", "Site in exception list", "Pinned certificate", or "TLS version/cipher" each points to a different fix.
- If the log shows inspection was performed, the client probably does not trust the inspection CA. Check whether users see a certificate warning for that site only, and whether the CA is deployed through MDM/GPO to all endpoints. Outlook and Teams using their own certificate stores or bypassing the proxy is consistent with a client-side trust problem, not a gateway one.
- If the log shows "Bypass", inspect the blade's exception list and the "do not inspect" categories, and confirm nobody added the SaaS vendor domain as an exception during the last incident.
- If inspection is on and the CA is trusted, then the application is likely pinning its certificate or using a non-browser client. Test from a browser with the CA installed and from a client that does not trust the CA, and compare.
Rules of engagement. Do not disable the blade to test; use a narrow test rule and a single test user. Enable the inspection debug on one cluster member only, for a bounded window, and remove it afterwards. If the vendor application genuinely pins certificates, the correct outcome is a documented, time-limited bypass scoped to that application and destination – not a cluster-wide change.
2. CPU hits 90-95% every morning while the CEO says the gateway is now too expensive to run. What would you examine and what would you change in the profiles and rule base?
Read the worked answer
First establish what the CPU is doing. Check whether the spike is kernel, inspection daemons, or logging, using cpview on both members. Look for a correlation with a scheduled job (backup, patching, an internal scan) rather than assuming it is user traffic. Confirm SecureXL is accelerating the bulk of the traffic with fwaccel stats, and check whether the Strict profile is really scoped to 300 finance users – a Strict rule placed above the Recommended rule applies only to those users, but if the order is inverted the strict settings hit everyone.
Profile design changes.
- Do not inspect every category. Inspect business-relevant categories and bypass high-bandwidth, low-risk ones.
- Use Threat Extraction for downloads rather than full inspection where the risk is a malicious document.
- Set size limits (hold/limit) so large files do not occupy inspection resources for minutes.
- Apply profiles on the rules that need them instead of a blanket rule, and remove logging from high-hit rules that nobody reads.
- Keep Forensics and full packet capture off for bulk traffic; they are the biggest silent cost multipliers.
Validate. Re-measure the 09:00 window for three days with the same cpview sampling, and record the change in the audit trail. If the spike persists with unchanged traffic, revisit the sizing conversation with real data instead of a bigger licence.
3. Resolve the blocked patch tool and the finance PDF complaints. What is the defensible answer when the application owners want both problems simply turned off?
Read the worked answer
Blocked admin tool (false positive). Confirm from the log which protection and indicator fired, and verify that the binary is genuinely the vendor's signed build (hash and signature from the vendor's own distribution). Then:
- Create an exception in the Threat Prevention policy scoped to that specific protection, that specific file hash or source, and the profile in use – not a global "disable protection".
- Attach an owner and an expiry date so it is reviewed, and report it upstream as a false positive so the indicator is corrected for everyone.
- Re-run the patch on a small pilot group before releasing to 400 servers.
Finance PDF handling. Threat Extraction is deliberately replacing the attachment with a sanitized copy. That is the designed behaviour, not a defect. If finance genuinely must receive the original, configure the profile so the original is delivered only when the file is confirmed clean, and do it for the finance profile only, with a written risk acceptance from the business owner.
Defensible answer. "Turning it off" is not on the table: it removes protection for 6,000 users to solve two narrow cases. The correct trade is the narrowest possible exception, time-limited, owned, logged, and reviewed – with the residual risk signed off by the business owner. Document both exceptions in one place so the next auditor sees the rationale, not just the gap.