Deploy SSL Decryption Using Best Practices

Generate and distribute keys and certificates for Decryption policies.
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, or POCs.
Generate a unique subordinate Forward Trust CA for each firewall. Separate subordinate CAs enable you to revoke a certificate when you decommission a device or device pair without affecting the rest of the deployment and reduce the impact if you need to revoke a certificate. Separate CA certificates help technical support troubleshoot user issues because the certificate error message includes information about the firewall the traffic traversed. Although using one Forward Trust subordinate CA on all firewalls is easier to deploy, using a separate certificate on each firewall provides the best security. Different PKI platforms have different features for scaling certificate management.
If you don’t 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. If the firewall self-signed Root CA isn’t 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 your plan calls for using an HSM, store the keys on the HSM.
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 protocol versions, key exchange algorithms, encryption algorithms, and authentication algorithms, and apply to SSL Forward Proxy and SSL Inbound Inspection traffic. For SSL 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 TLS protocol available. 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 only to sites that don’t support TLSv1.2. Similarly, create separate Decryption profiles for necessary sites that don’t support strong algorithms and for different URL Categories to fine tune security vs. performance.
No Decryption profiles control server certificate verification for traffic you choose not to decrypt. Block sessions with expired certificates and untrusted issuers.
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.
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), and application ports that you choose not to decrypt. Place these rules at the top of the Decryption rulebase, before rules that decrypt traffic, and apply a No Decryption profile to them. This prevents inadvertently decrypting traffic that you don’t want to decrypt.
Use URL Categories, Custom URL Categories, or 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. The firewall implements EDL changes dynamically, without a commit action.
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.
Use the No Decryption profile for traffic that you choose not to decrypt to apply SSL server verification controls to the encrypted traffic.
Create policy rules to decrypt the rest of the traffic by configuring SSL Forward Proxy, SSL Inbound Inspection, and SSH Proxy. If you can’t decypt everything, 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 consider configuring Multi-Factor Authentication to prevent unauthorized SSH access.
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. As sites that break decryption technically are discovered, Palo Alto Networks content updates add them to the SSL Decryption Exclusion list. (Decrypting sites that block decryption technically results in blocking that traffic.)
In Security policy, block Quick UDP Internet Connections (QUIC) protocol.
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. Block both the QUIC application and UDP ports 80 and 443 to force the browser to use TLS.
Forward decrypted traffic to WildFire to inspect it for malware.
Roll out decryption slowly.
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.