Create the Data Center Best Practice Decryption Profiles

1. Configure the firewall to perform CRL/OCSP checks to ensure that certificates presented during decryption are valid.
2. Configure the SSL DecryptionSSL Protocol Settings to block vulnerable SSL/TLS versions such as TLSv1.0, TLSv1.1, and SSLv3, and to avoid weak encryption algorithms such as RC4 and 3DES, and weak authentication algorithms such as MD5 and SHA1.
   SSL Protocol Settings apply to all decrypted traffic.

   Set the protocol Min Version to TLSv1.2 and the Max Version to Max to block weak protocols. Use the strongest TLS protocol that you can. Create separate Decryption policies and profiles to maximize security. For example, if legacy sites you need for business purposes only support weaker protocols, create a separate Decryption profile to allow the weaker protocol and apply it in a Decryption policy only to sites that don’t support at least TLSv1.2. This also applies to necessary business sites that don’t support strong algorithms and for different URL Categories to fine tune security vs. performance.

   If the site doesn’t house a legitimate business application, don’t weaken your security posture to support the site—weak protocols and ciphers contain known vulnerabilities that attackers can exploit. If the site belongs to a category of sites that you don’t need for business purposes, use URL Filtering to block access to the entire category. Don’t support weak protocols or weak encryption or authentication algorithms unless you must do so to support important legacy sites.

   Set the Max Version to Max rather than to a particular version so that as the protocols improve, the firewall automatically supports the newest and best protocols. Whether you intend to attach a Decryption profile to a Decryption policy rule that governs inbound (SSL Inbound Inspection) or outbound (SSL Forward Proxy) traffic, avoid allowing weak algorithms.

   Many mobile applications use pinned certificates. Because TLSv1.3 encrypts certificate information, the firewall can’t automatically add these mobile applications to the SSL Decryption Exclusion List. For these applications, ensure that the Decryption profile Max Version is set to TLSv1.2 or apply a No Decryption policy to the traffic.
3. Configure the SSL DecryptionSSL Forward Proxy settings for outbound traffic to block exceptions during TLS negotiation and block sessions that can’t be decrypted.
   In some cases, the best practice settings depend on your company’s security compliance rules. Apply the SSL Forward Proxy Decryption profile to security policy rules that control outbound traffic.

   Block exceptions during TLS negotiation and block sessions that can’t be decrypted.

   • Server Certificate Verification—Whether to check the Block sessions on certificate status check timeout box 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.
     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.
     Although the best practice is to use a proper certificate, some certificates leave the Subject Alternate Name (SAN) field blank, which can cause firewalls to reject those certificates. Check Append certificate’s CN value to SAN extension to automatically copy the certificate number to the SAN field if the SAN field is blank, so that if you do business with sites that don’t populate the certificate’s SAN field, you can accept their certificates. Otherwise, the sites need to regenerate their certificates to conform to proper practice and populate the SAN field.
     Block all other server certificate verification exceptions.
   • Unsupported Mode Checks—If you don’t block sessions with unsupported versions and unsupported cipher suites, then users receive a warning message that they can click through to reach the risky website. The reason you configure tight SSL Protocol Settings is to block and protect you from servers that use these weak (risky) protocol versions and algorithms. In addition, blocking sessions with unsupported mode checks protects you from malicious backdoors and other threats that use custom and non-standard encryption to obfuscate their activities.
     Block sessions with client authentication enables you to choose whether to allow or block sessions that use client authentication. Although server authentication can be the only authentication used to establish a session, some sites use mutual authentication, where both the server and the client authenticate to establish a session. Client authentication using an X.509 Digital Certificate is similar to server authentication in that both methods use a digital certificate issued by a trusted Certificate Authority to authenticate a session. The client certificate acts as a digital identifier for the client, resides on the client device, and can’t be ported to other devices. However, client authentication prevents the firewall from decrypting the session because the firewall needs both the client and server certificates to perform bi-directional decryption, but the firewall only knows the server certificate. This breaks decryption for client authentication sessions.
     If you don’t enable 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 in its local decrypt exclude cache that contains the server URL/IP address, the application, and the Decryption profile. Entries remain in the cache for 12 hours and then age out. If the same user or a different user attempts to access the serer within 12 hours using client authentication, the firewall matches the session to the decrypt exclude cache entry, does not attempt to decrypt the traffic, and allows the encrypted session.
     If the exclude cache becomes full, the firewall purges the oldest entries as new entries arrive. If you change the Decryption policy or profile, the firewall flushes the exclude cache because changing the policy or profile can change the classification outcome of the session.
     If you enable Block sessions with client authentication, the firewall blocks sessions that use client authentication, with the exception of sessions from sites on the SSL Decryption Exclusion list (DeviceCertificate ManagementSSL Decryption Exclusion).
     You may need to allow traffic on your network from other sites that use client authentication in addition to 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 house the application. To increase security even more, you can require Multi-Factor Authentication to complete the user login process.
     For all other traffic, apply the Decryption profile that blocks sessions with client authentication.
   • Failure Checks—If you don’t Block sessions if resources not available, the risk is that a lack of processing resources may allow potentially dangerous connections. If you block sessions for which resources aren’t available, it may affect the user experience. 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.
     If you use a Hardware Security Module (HSM) to store your private keys, whether you check Block sessions if HSM not available 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).
   • 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.
4. Configure the SSL DecryptionSSL Inbound Inspection settings to inspect traffic from an external client to your internal servers and block suspicious sessions.
   Apply the SSL Inbound Inspection Decryption profile to security policy rules that control inbound traffic.
   • Unsupported Mode Checks—The firewall can’t decrypt session versions and ciphers that the firewall doesn’t support. To prevent attackers from using unsupported versions and ciphers to sneak onto the network, block session versions and cipher suites that the firewall doesn’t support. In addition, blocking sessions with unsupported mode checks protects you from malicious backdoors and other threats that use custom and non-standard encryption to obscure their activities.
     On the server, enable only the ciphers that you support on the firewall. Ensuring this compatibility makes the negotiation between the client and the server smoother.
   • Failure Checks—If you don’t Block sessions if resources not available, the risk is that a lack of processing resources may allow potentially dangerous connections. If you block sessions for which resources aren’t available, it may affect the user experience. 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.
     If you use a Hardware Security Module (HSM) to store your private keys, whether you check Block sessions if HSM not available 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).
   • 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.
5. For SSH traffic, configure SSH Proxy Decryption profile settings.
   SSH Decryption allows normally routed SSH traffic and denies SSH tunneling (SSH port forwarding) traffic, but doesn’t perform content or threat inspection on the SSH traffic. SSH tunneling sessions can tunnel X11 Windows packets and TCP packets. One SSH connection may contain multiple channels. When you apply an SSH Decryption profile to traffic, for each channel in the connection, the firewall examines the App-ID of the traffic and identifies the channel type. The channel type can be:

   • session
   • X11
   • forwarded-tcpip
   • direct-tcpip

   When the channel type is session, the firewall identifies the traffic as allowed SSH traffic such as SFTP or SCP. When the channel type is X11, forwarded-tcpip, or direct-tcpip, the firewall identifies the traffic as SSH tunneling traffic and blocks it.

   For most user groups, you probably won’t allow SSH traffic in the data center. SSH is usually used for remote access to servers, which is not a capability you want most users to have because it places your data center servers at greater risk, for access to Linux servers, and for file transfers. You can’t decrypt SSH traffic, so anyone who uses SSH to access data center resources must be trusted—and even so, all of the threat profiles should be attached to any rule that allows SSH access to scan for malware, viruses, spyware, etc.

   An example use case for SSH is IT personnel who manage and maintain data center servers and use SSH for remote access.
   • Unsupported Mode Checks—The firewall can’t decrypt session versions and ciphers that the firewall doesn’t support and unsupported versions and ciphers may be vulnerable. To prevent attackers from using unsupported versions and ciphers to sneak onto the network, block session versions and cipher suites that the firewall doesn’t support. In addition, blocking sessions with unsupported mode checks protects you from malicious backdoors and other threats that use custom and non-standard encryption to obscure their activities.
   • Failure Checks—If you don’t Block sessions if resources not available, the risk is that a lack of processing resources may allow potentially dangerous connections. If you block sessions for which resources aren’t available, it may affect the user experience. 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.
6. For traffic that you choose not to decrypt, configure the No Decryption settings to block encrypted sessions destined for sites with expired certificates or untrusted issuers.
   Apply the No Decryption profile only to traffic that you choose not to decrypt because of regulations or compliance rules, not to traffic that can’t be decrypted because of technical reasons, such as a pinned certificate (add that traffic to the SSL Decryption Exclusion List). The best practice is to decrypt as much data center traffic as possible.

   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.