The SSL Inbound Inspection Decryption profile blocks
risky inbound sessions and provides session failure checks.
The SSL Inbound Inspection Decryption profile (
SSL 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.
For PFS key exchange algorithms (DHE or ECDHE), because
PFS generates a new key with every session, the firewall acts as
a man-in-the-middle proxy between the external client and the internal
server. When the firewall is a proxy device, it can’t decrypt some
sessions, such as sessions with client authentication or pinned
certificates. Being a proxy device also means that the firewall
does not support High Availability (HA) sync for decrypted SSL sessions.
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:
Block sessions with unsupported versions
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.
Block sessions with unsupported cipher suites
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
of the Decryption profile.
Block sessions if resources not available
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.1 supports two members in
an HSM HA pair).