SSL Forward Proxy Decryption Profile

• Block sessions with expired certificates—Always 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.
• Block sessions with untrusted issuers—Always check this box to block sessions with servers that have untrusted certificate issuers. An untrusted issuer may indicate a man-in-the-middle attack, a replay attack, or other attack.
• Block sessions with unknown certificate status—Blocks the SSL/TLS session when a the certificate revocation status of the server returns with the status “unknown”. Because certificate status may be unknown for multiple reasons, for general decryption security, checking this box usually tightens security too much. However, in higher-security areas of the network such as the data center, checking this box makes sense.
• Block sessions on certificate status check timeout—Whether to block sessions if the status check times out depends on your company’s security compliance stance because it’s a tradeoff between tighter security and a better user experience. Certificate status verification examines the Certificate Revocation List (CRL) on a revocation server or uses Online Certificate Status Protocol (OCSP) to find out if the issuing CA has revoked the certificate and the certificate should not be trusted. However, revocation servers can be slow to respond, which can cause the session to timeout and the firewall to block the session even though the certificate may be valid. If you Block sessions on certificate status check timeout and the revocation server is slow to respond, you can use DeviceSetupSessionDecryption Settings and click Certificate Revocation Checking to change the default timeout value of five seconds to another value. For example, you could increase the timeout value to eight seconds, as shown in the following figure. Enable both CRL and OCSP certificate revocation checking because server certificates can contain the CRL URL in the CRL Distribution Point (CDP) extension or the OCSP URL in the Authority Information Access (AIA) certificate extension.

• Restrict certificate extensions—Checking this box limits the certificate extensions in the server certificate to key usage and extended key usage and blocks certificates with other extensions. However, in certain deployments, some other certificate extensions may be necessary, so only check this box if your deployment requires no other certificate extensions.
• Append certificate’s CN value to SAN extension—Checking this box ensures that when a browser requires a server certificate to use a Subject Alternative Name (SAN) and doesn’t support certificate matching based on the Common Name (CN), if the certificate doesn’t have a SAN extension, users can still access the requested web resources because the firewall adds the SAN extension (based on the CN) to the impersonation certificate.

• Block sessions with unsupported versions—When you configure the SSL Protocol Settings Decryption Profile, you specify the minimum version of SSL protocol to allow on your network to reduce the attack surface by blocking weak protocols. Always check this box to block sessions with the weak SSL/TLS protocol versions that you have chosen not to support.
• Block sessions with unsupported cipher suites—Always check this box to block sessions if the firewall doesn’t support the cipher suite specified in the handshake. You configure which algorithms the firewall supports on the SSL Protocol Settings tab of the Decryption profile.
• Block sessions with client authentication—If you have no critical applications that require client authentication, block it because firewall can’t decrypt sessions that require client authentication. The firewall needs both the client and the server certificates to perform bi-directional decryption, but with client authentication, the firewall only knows the server certificate. This breaks decryption for client authentication sessions. When you check this box, the firewall blocks all sessions with client authentication except sessions from sites on the SSL Decryption Exclusion list (DeviceCertificate ManagementSSL Decryption Exclusion).
  If you don’t Block sessions with client authentication, when the firewall attempts to decrypt a session that uses client authentication, the firewall allows the session and adds an entry that contains the server URL/IP address, the application, and the Decryption profile to its Local Decryption Exclusion Cache.
  You may need to allow traffic on your network from sites that use client authentication and are not in the Predefined sites on the SSL Decryption Exclusion list. Create a Decryption profile that allows sessions with client authentication. Add it to a Decryption policy rule that applies only to the server(s) that host the application. To increase security even more, you can require Multi-Factor Authentication to complete the user login process.

• Block sessions if resources not available—If you block sessions when no firewall processing resources are available, the firewall drops traffic when it doesn’t have the resources to decrypt the traffic. If you don’t block sessions when the firewall can’t process decryption due to a lack of resources, then traffic that you want to decrypt enters the network still encrypted and therefore is not inspected. However, blocking sessions when resources aren’t available may affect the user experience by making sites that users normally can reach temporarily unreachable. Whether to implement this failure check depends on your company’s security compliance stance and the importance of the user experience, weighed against tighter security. Alternatively, consider using firewall models with more processing power so that you can decrypt more traffic.
• Block sessions if HSM not available—If you use a Hardware Security Module (HSM) to store your private keys, whether you use one depends on your compliance rules about where the private key must come from and how you want to handle encrypted traffic if the HSM isn’t available. For example, if your company mandates the use of an HSM for private key signing, then block sessions if the HSM isn’t available. However, if your company is less strict about this, then you can consider not blocking sessions if the HSM isn’t available. (If the HSM is down, the firewall can process decryption for sites for which it has cached the response from the HSM, but not for other sites.) The best practice in this case depends on your company’s policies. If the HSM is critical to your business, run the HSM in a high-availability (HA) pair (PAN-OS 8.1 supports two members in an HSM HA pair).
• Block downgrade on no resource—Prevents the firewall from downgrading TLSv1.3 to TLSv1.2 if the firewall has no available TLSv1.3 processing resources. If you block the downgrade, then when the firewall runs out of TLSv1.3 resources, it drops traffic that uses TLSv1.3 instead of downgrading it to TLSv1.2. If you don’t block downgrade, then when the firewall runs out of TLSv1.3 resources, it downgrades to TLSv1.2. However, blocking downgrade when resources aren’t available may affect the user experience by making sites that users normally can reach temporarily unreachable. Whether to implement this failure check depends on your company’s security compliance stance and the importance of the user experience, weighed against tighter security. You may want to create a separate Decryption policy and profile to govern decryption for sensitive traffic for which you don’t want to downgrade the TLS version.