End-of-Life (EoL)

Deploy SSL Decryption Using Best Practices

Following SSL Decryption deployment best practices help to ensure a smooth, prioritized rollout and that you decrypt the traffic you need to decrypt to safeguard your network.
    • If you have an Enterprise PKI, generate the Forward Trust CA certificate for forward proxy traffic from your Enterprise Root CA. Otherwise, generate a self-signed Root CA certificate on the firewall, create a subordinate CA on that firewall, and then distribute the self-signed certificate to all client systems. Self-signed certificates are intended for lab testing, small deployments, and POCs.
    • Generate a unique subordinate Forward Trust CA for each firewall (or one Forward Trust CA for all firewall, depending on your planning—one certificate is easier to deploy, but separate certificates provide the best security and other benefits). Different PKI platforms have different features for scaling certificate management.
    • If you do not use an Enterprise CA, import the Forward Trust CA certificate into the client systems’ trust CA storage.
    • Do not import the Forward
      Untrust
      CA certificate into the CA trust storage on client systems or the untrust certificate won’t act as a trigger for untrusted sites. (However, if the firewall self-signed Root CA is not installed as a trusted issuer on client systems, you can use a self-signed Forward Untrust certificate.)
    • Use an automated method to distribute the Forward Trust certificates to connected devices, such as the Palo Alto Networks GlobalProtect Portal, Microsoft AD Certificate Services (using Group Policy Objects), commercial tools, or open source tools.
    • If you generate the certificate from your Enterprise Root CA, import the certificate on the firewall.
    • Back up the private key for the firewall’s Forward Trust CA certificate (not the firewall’s master key) in a secure repository so that if an issue occurs, you can still access the Forward Trust CA certificate.
    • If you generate certificates and private keys from your Enterprise Root CA, block the export of private keys. (You can install them on new firewalls and Panoramas from your enterprise CA, so you don’t need to export them from PAN-OS.)
    • If your plan calls for using an HSM, store the private keys on the HSM.
  1. Configure Decryption profiles to control protocols, certificate verification, and failure handling.
    • SSL Forward Proxy Decryption profiles control server certificate verification, session modes, and failure checks for outbound traffic. Block sessions with expired certificates, untrusted issuers, unsupported versions, and unsupported cipher suites. Block sessions with client authentication unless an important application requires it, in which case you should create a separate Decryption profile that allows client authentication and apply it only to traffic that requires client authentication.
    • SSL Inbound Inspection Decryption profiles control session modes and failure checks for inbound traffic. Block sessions with unsupported versions and unsupported cipher suites.
    • SSL Protocol Settings control cipher suite elements: protocol versions, key exchange algorithms, encryption algorithms, and authentication algorithms for SSL Forward Proxy and SSL Inbound Inspection traffic. Use the strongest ciphers that you can. For Forward Proxy, set the protocol
      Min Version
      to
      TLSv1.2
      and the
      Max Version
      to
      Max
      to block weak protocols. For SSL Inbound Inspection, create separate profiles with protocol settings that match the capabilities of the server(s) whose inbound traffic you are inspecting.
      Use the strongest cipher suite that you can. Create separate Decryption policies and profiles to maximize security. If legacy sites that you need for business purposes only support weaker ciphers, create a separate Decryption profile to allow the that traffic and apply it in a Decryption policy only to the necessary sites. Use the same technique to fine tune security vs. performance for different URL categories.
      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.
    • No Decryption profiles control server certificate verification for traffic you choose not to decrypt. Block sessions with expired certificates and untrusted issuers.
      Do not apply a No Decryption profile to TLSv1.3 traffic. The certificate information is encrypted, so the firewall cannot block sessions based on certificate information.
    • For SSL Forward Proxy and No Decryption traffic, configure both Certificate Revocation List (CRL) and Online Certificate Status Revocation (OCSP) certificate revocation checks to verify that site certificates have not been revoked.
    • SSH Proxy profiles control session modes and failure checks for SSH tunneled traffic. Block sessions with unsupported versions and unsupported algorithms.
    The best practice Decryption profile settings for the data center and for the perimeter (internet gateway) use cases differ slightly from the general best practice settings.
  2. Configure Decryption policy rules to define the traffic to decrypt and to make policy-based exceptions for traffic you
    choose
    not to decrypt.
    • Create policy rules to except specific destination IP addresses (for example, finance servers), source users and groups (for example, executives or HR personnel), source devices, and application ports that you choose not to decrypt. Place these rules at the top of the Decryption rulebase, before rules that decrypt traffic. For all traffic except TLSv1.3 traffic, attach a No Decryption profile to them to apply SSL server certificate verification controls to the encrypted traffic. This prevents inadvertently decrypting traffic that you don’t want to decrypt.
    • Use URL Categories, Custom URL Categories, and External Dynamic Lists (EDLs) to specify URLs not to decrypt, such as financial-services, health-and-medicine, government, and any other categories you don’t want to decrypt for business, legal, or regulatory reasons. Use an EDL in environments with dynamically changing IP addresses (for example, Office 365) or frequent membership changes to update without having to commit.
      Create an EDL or Custom URL Category that contains all the categories you choose not to decrypt so that you only need one Decryption policy rule for them.
      Place these rules above rules that decrypt traffic in the Decryption rulebase.
    • If you use Decryption mirroring to copy and send decrypted traffic to a traffic collection tool, be aware of local privacy regulations that may prohibit mirroring or control the traffic you can mirror.
    • Create policy to decrypt the rest of the traffic by configuring SSL Forward Proxy, SSL Inbound Inspection, and SSH Proxy rules. Always decrypt the online-storage-and-backup, web-based-email, web-hosting, personal-sites-and-blogs, content-delivery-networks, and high-risk URL categories. Limit SSH Proxy to administrators who manage network devices, log all SSH traffic, and configure Multi-Factor Authentication to prevent unauthorized SSH access.
  3. Add sites to the SSL Decryption Exclusion list (
    Device
    Certificate Management
    SSL Decryption Exclusion
    ) if they break decryption technically during POC testing and are not already on the exclusion list. (Decrypting sites that block decryption technically results in blocking that traffic.)
  4. Chrome and some other browsers establish sessions using QUIC instead of TLS, but QUIC uses proprietary encryption that the firewall can’t decrypt, so potentially dangerous traffic may enter the network as encrypted traffic. Create two rules, one to block the QUIC application on standard ports and one to block UDP ports 80 and 443. Blocking QUIC forces the browser to use TLS.
  5. Forward decrypted traffic to WildFire to inspect it for malware.
  6. Decrypt a few URL Categories, review user feedback, and run reports to ensure that decryption works as expected. Gradually decrypt more URL Categories until you reach your goal. Start with the highest priority traffic (URL categories most likely to harbor malicious traffic, such as gaming), and decrypt more as you learn from experience and refine the process. A more conservative alternative is to decrypt URL Categories that don’t affect your business first, for example, news feeds.

Recommended For You