The 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
SSL/TLS traffic defined in the Inbound Inspection Decryption policies
to which you attach the profile. The following figure shows the general
best practice recommendations for Inbound Inspection Decryption
profile settings, but the settings you use also depend on your company’s
security compliance rules and local laws and regulations.
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—When
you configure the SSL Protocol Settings Decryption Profile, you specify
the minimum version of TLS 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 and 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.
Failure Checks:
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.