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.
- 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 whenever 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 ForwardUntrustCA 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.
- 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 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 protocolMin VersiontoTLSv1.2and theMax VersiontoMaxso the firewall always supports the strongest available 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.Decrypting TLS traffic forces browsers using HTTP/2 to fall back to HTTP 1.1 because the firewall can’t decrypt HTTP/2 traffic. Allow browsers to fall back to HTTP 1.1 to decrypt this traffic and keep potentially malicious encrypted traffic off your network.
- 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.
- Configure Decryption policy rules to define the traffic to decrypt and to make policy-based exceptions for traffic youchoosenot 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.
- 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, and content-delivery-networks 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 () 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.)DeviceCertificate ManagementSSL Decryption Exclusion
- In Security policy, block Quick UDP Internet Connections (QUIC) protocol unless, for business reasons, you want to allow encrypted browser traffic.Chrome and some other browsers establish sessions using QUIC instead of TLS/SSL, but QUIC uses proprietary encryption that the firewall can’t decrypt, so potentially dangerous traffic may enter the network as encrypted traffic. Blocking QUIC forces the browser to fall back to TLS/SSL.
- Forward decrypted traffic to WildFire to inspect it for malware.
- 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
Recommended videos not found.