HTTPS Inspection and Application Control Coverage Gap
An R82 gateway runs Application Control and URL Filtering. The policy blocks 'Peer-to-Peer File Sharing' and 'Anonymity' categories, and allows everything else. HTTPS inspection is enabled with a certificate signed by an internal CA that is pushed to all managed endpoints. Recently, the security team noticed that a popular encrypted file-sharing client is being used successfully from a subnet 10.30.7.0/24, while the same client is blocked from 10.30.8.0/24. Logs for 10.30.7.0/24 show the application identified as 'HTTPS' with no further classification. The bypass is not a rule-base exception.
1. Explain how the same client can be blocked on one subnet and allowed on another when the policy is identical.
Read the worked answer
Application Control and URL Filtering need to see the traffic. For HTTPS, that means HTTPS Inspection must be active for the connection. If inspection is bypassed, the gateway sees only an opaque TLS stream and classifies it as generic 'HTTPS', which matches the 'allow everything else' rule.
Likely causes specific to 10.30.7.0/24:
- The client is using a pinned certificate or a non-standard port; if the inspection policy has a bypass for that category/port, it is not decrypted.
- The internal CA certificate is not installed on hosts in 10.30.7.0/24 (e.g., a separate OU or unmanaged devices), so inspection fails open or is bypassed by policy.
- A bypass rule in the HTTPS inspection policy (e.g., by category or by destination) applies to that subnet's traffic.
So the difference is not the Access Control rule base but the inspection path: on 10.30.8.0/24 traffic is decrypted and identified; on 10.30.7.0/24 it is not.
2. What changes would you make to close the gap without breaking the endpoints that cannot trust the internal CA?
Read the worked answer
- Verify the CA distribution: confirm the internal CA root is in the trust store for 10.30.7.0/24 hosts (GPO/MDM). If they are unmanaged, they cannot be inspected without user action.
- Tighten the HTTPS inspection policy: remove broad bypass rules; add bypass only for categories that legally/practically must be excluded (e.g., banking, health). Use 'Bypass under' carefully - bypassing by category means those sites are never inspected.
- Fail-closed for the P2P/Anonymity categories: create an explicit rule blocking those categories before the allow-all, so even if inspection is bypassed, the category match (where possible via SNI/domain) still blocks.
- For uninspectable hosts: put them in a separate group with a stricter rule base (deny unknown HTTPS to non-corporate destinations) rather than allowing generic HTTPS.
- Monitor: add a log rule for 'HTTPS' with no application to detect uninspected flows and alert.