SSL Inbound Inspection Decryption Profile

The SSL Inbound Inspection Decryption profile blocks risky inbound sessions and provides session failure checks.
The SSL Inbound Inspection Decryption profile (ObjectsDecryption ProfileSSL DecryptionSSL Inbound Inspection) controls the session mode checks and failure checks for inbound traffic defined in the SSL Inbound Inspection Decryption policies to which you attach the profile. The following figure shows the general best practice recommendations for SSL Inbound Inspection Decryption profile settings, but the settings you use also depend on your company’s security compliance rules and local laws and regulations.
ssl-inbound-inspection-best-practice-decryption-profile.png
Unsupported Mode Checks. If you don’t block sessions with unsupported modes, users receive a warning message if they connect with potentially unsafe servers, and they can click through that message and reach the potentially dangerous site. Blocking these sessions protects you from servers that use weak, risky protocol versions and algorithms:
  1. 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 protocol versions that you have chosen not to support.
  2. 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 SSL handshake. You configure which algorithms the firewall supports on the SSL Protocol Settings tab of the Decryption profile.
Failure Checks:
  • Block sessions if resources not available—If you don’t block sessions when firewall processing resources aren’t available, then encrypted traffic that you want to decrypt enters the network still encrypted, risking allowing potentially dangerous connections. However, blocking sessions when firewall processing resources aren’t available may affect the user experience by making sites that users normally can reach temporarily unreachable. Whether to implement failure checks depends on your company’s security compliance stance and the importance to your business 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.0 supports two members in an HSM HA pair).

Related Documentation