Profile for No Decryption
The No Decryption profile blocks risky sessions for traffic that you choose not to decrypt by policy rule.
No Decryption profiles (
) perform server verification checks for traffic that you choose not to decrypt. You attach a No Decryption profile to a “No Decryption” Decryption policy that defines the traffic to exclude from decryption. (Don’t use policy to exclude traffic that you can’t decrypt because a site breaks decryption for technical reasons such as a pinned certificate or mutual authentication. Instead, add the hostname to the Decryption Exclusion List.) The following figure shows the general best practice recommendations for the No Decryption profile settings, but the settings you use also depend on your company’s security compliance rules and local laws and regulations.
- Block sessions with expired certificates—Check this box to block sessions with servers that have expired certificates and prevent access to potentially insecure sites. If you don’t check this box, users can connect with and transact with potentially malicious sites and see warning messages when they attempt to connect, but the connection is not prevented.
Do not attach a No Decryption profile to Decryption policies for TLSv1.3 traffic that you don’t decrypt. Unlike previous versions, TLSv1.3 encrypts certificate information, so the firewall has no visibility into certificate data and therefore cannot block sessions with expired certificates or untrusted issuers, so the profile has no effect. (The firewall can perform certificate checks with TLSv1.2 and earlier because those protocols do not encrypt certificate information and you should apply a No Decryption profile to their traffic.) However, you should create a Decryption policy for TLSv1.3 traffic that you don’t decrypt because the firewall doesn’t log undecrypted traffic unless a Decryption policy controls that traffic.
(Applies to TLSv1.2 and earlier) If you choose to allow sessions with untrusted issuers (not recommended) and only
Block sessions with expired certificates, there is a scenario in which a session with a trusted, expired issuer may be blocked inadvertently. When the firewall’s certificate store contains a valid, self-signed Trusted CA and the server sends an expired CA in the certificate chain, the firewall does not check its certificate store. Instead, the firewall blocks the session based on the expired CA when it should find the trusted, valid alternative trust anchor and allow the session based on that trusted self-signed certificate.
To avoid this scenario, in addition to
Block sessions with expired certificates, enable
Block sessions with untrusted issuers. This forces the firewall to check its certificate store, find the self-signed Trusted CA, and allow the session.
Recommended For You
Recommended videos not found.