Decryption Best Practices

Version 10.0

paloaltonetworks.com/documentation
Contact Information
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
www.paloaltonetworks.com/company/contact-support

About the Documentation

• For the most recent version of this guide or for access to related documentation, visit the Technical
Documentation portal www.paloaltonetworks.com/documentation.
• To search for a specific topic, go to our search page www.paloaltonetworks.com/documentation/
document-search.html.
• Have feedback or questions for us? Leave a comment on any page in the portal, or write to us at
documentation@paloaltonetworks.com.

Copyright
Palo Alto Networks, Inc.
www.paloaltonetworks.com

© 2020-2020 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo
Alto Networks. A list of our trademarks can be found at www.paloaltonetworks.com/company/
trademarks.html. All other marks mentioned herein may be trademarks of their respective companies.

Last Revised
October 28, 2020

2 DECRYPTION BEST PRACTICES |

Table of Contents
Decryption Best Practices.................................................................................5
Plan Your SSL Decryption Best Practice Deployment....................................................................... 7
Deploy SSL Decryption Using Best Practices....................................................................................10
Follow Post-Deployment SSL Decryption Best Practices...............................................................13

TABLE OF CONTENTS iii

iv TABLE OF CONTENTS
Decryption Best Practices
You can’t protect your network against threats you can’t see and inspect. Gartner predicts
that in 2020, more than 70 percent of new malware campaigns will use various forms of
encryption. Google’s Transparency Report shows that no matter how you analyze Google web
traffic, in most cases, more than 90 percent of it is encrypted. Decrypt that traffic to protect
your network against hidden threats.
This document is a streamlined checklist of pre-deployment, deployment, and post-
deployment best practices that you can follow to implement decryption. Each section
includes links to detailed information in the PAN-OS Admin Guide, including how to configure
Decryption policy rules and profiles.

> Plan Your SSL Decryption Best Practice Deployment

> Deploy SSL Decryption Using Best Practices
> Follow Post-Deployment SSL Decryption Best Practices

5
6 DECRYPTION BEST PRACTICES | Decryption Best Practices
© 2020 Palo Alto Networks, Inc.
Plan Your SSL Decryption Best Practice
Deployment
Prepare to deploy decryption by developing a decryption strategy and roll-out plan. Turning on decryption
may change the way users interact with some applications and websites, so planning, testing, and user
education are critical to a successful deployment.

STEP 1 | Set goals.

Plan to decrypt as much traffic that is not private or sensitive as your firewall resources permit. This
reduces the attack surface by exposing and preventing encrypted threats. Understand local laws and
regulations about the traffic you can legally decrypt and user notification requirements.
Migrate from port-based to application-based Security policy rules before you create and deploy
Decryption policy rules. If you create Decryption rules based on port-based Security policy and then
migrate to application-based Security policy, the change could cause the Decryption rules to block
traffic that you intend to allow because Security policy rules are likely to use application default ports
to prevent traffic from using non-standard ports. Migrating to App-ID based rules before deploying
decryption ensures that when you test your decryption deployment, you’ll discover Security policy
misconfigurations and fix them before rolling decryption out to the general user population.

STEP 2 | Work with and educate stakeholders such as legal, finance, HR, executives, security, and IT/
support to develop a decryption deployment strategy.
Get the required approvals to decrypt traffic to secure the enterprise.
Identify and prioritize the traffic to decrypt:
• Decide which applications to decrypt (sanctioned, unsanctioned). Don’t allow encrypted
unsanctioned applications.
• Decide which devices to decrypt (corporate, BYOD, mobile, etc.).

Enterprises don’t control BYOD devices. If you allow BYOD devices on your
network, decrypt their traffic and subject it to the same Security policy that
you apply to other network traffic. To do this, redirect BYOD users through an
Authentication Portal, instruct them how to download and install the CA certificate,
and clearly notify users that their traffic will be decrypted. Educate BYOD users
about the process and include it in your company’s privacy and computer usage
policy.
• Decide if you want to use the same decryption policy for different groups, such as different
employee groups, contractors, partners, and guests.
Identify traffic you can’t decrypt:
• Traffic that breaks decryption for technical reasons such as certificate pinning, unsupported
ciphers, or mutual authentication.
• Traffic that you choose not to decrypt such as financial, health, government, and other sensitive
categories, including users and groups such as executives.
• Fully understand the traffic you except from decryption. You don’t have visibility into encrypted
traffic and the firewall can’t apply threat prevention profiles to encrypted traffic.
Prepare updated legal and HR computer usage policies to distribute to all employees, contractors,
partners, guests, and any other network users so that when you roll out decryption, users understand
their data can be decrypted and scanned for threats.

DECRYPTION BEST PRACTICES | Decryption Best Practices 7

© 2020 Palo Alto Networks, Inc.
 Decide how to handle certificate verification. Your business model may require tradeoffs between
security and the user experience. Understanding how you want to handle certificate verification
helps determine how you configure SSL Forward Proxy Decryption profiles.
Identify the traffic you want to log. Be aware of local legal and regulatory differences, and how they
affect which traffic you can log and where you can store logs.

Place firewalls where they can see all of the network traffic so that no encrypted traffic
inadvertently gains access to your network because it bypasses the firewall.

STEP 3 | Develop a plan for rolling out your public key infrastructure (PKI).
If you have an existing PKI, generate the SSL Forward Trust CA certificate from your Enterprise Root
CA as a subordinate certificate. This makes deployment easier because network devices already trust
the Enterprise Root CA, so you won’t run into certificate issues. If you don’t have an Enterprise Root
CA, consider getting one.
Alternatively, generate a self-signed Root CA certificate on the firewall and create a subordinate
Forward Trust CA certificate on that firewall to install on network devices. Self-signed certificates are
best for small companies that don’t have an Enterprise Root CA and for proof-of-concept (POC) trials.

Similarly to BYOD devices, enterprises don’t control guest devices. If you allow guest
devices on your network, decrypt their traffic and subject it to the same Security policy
that you apply to other network traffic. To do this, redirect guest users through an
Authentication Portal, instruct them how to download and install the CA certificate,
and clearly notify users that their traffic will be decrypted. Include the process in your
company’s privacy and computer usage policy.
Generate separate CA certificates for Forward Trust and Forward Untrust. Do not use the same PKI
subordinate CA for both certificates and do not sign the Forward Untrust certificate with the Trusted
Root CA! The Forward Untrust certificate warns users that the certificate signing the server is not
legitimate and that they should not proceed to the site. If the Trusted Root CA signs the Untrust
certificate, then clients trust certificates that should be untrusted because clients trust the Root CA.
Generate a separate subordinate Forward Trust CA certificate for each firewall. Using separate
subordinate CAs enables you to revoke a certificate when you decommission a device (or device
pair) without affecting the rest of the deployment and reduces 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.
If you need additional security for your private keys, consider storing them in an HSM.

STEP 4 | Take a baseline measurement of firewall performance to understand resource consumption

and available firewall resources so that you can compare performance after you deploy
decryption and estimate the size of the firewall deployment required to support the amount of
traffic you want to decrypt.
Work with your Palo Alto Networks SE/CE to size the firewall deployment and avoid sizing mistakes.
Note the currently available firewall resources. In general, the tighter your security, the more
resources decryption consumes. Factors that affect how much traffic you can decrypt include:
• The amount of SSL traffic you want to decrypt.
• TLS protocol version.
• Key size.
• Key exchange algorithm. Perfect forward secrecy (PFS) ephemeral algorithms such as DHE and
ECDHE consume more resources than RSA, but provide greater security because the firewall
generates a new cipher key for each session. If an attacker compromises a session key, PFS

8 DECRYPTION BEST PRACTICES | Decryption Best Practices

© 2020 Palo Alto Networks, Inc.
 prevents the attacker from using it to decrypt other sessions between the same client and server,
while RSA does not.
• Certificate authentication. RSA certificate authentication (this is not the same as the RSA key
exchange algorithm) consumes fewer CPU cycles than ECDSA certificate authentication but
ECDSA provides the highest level of security.
• Encryption algorithm. The key exchange algorithm determines whether the encryption algorithm
is PFS or RSA.
• The firewall model and resources. Newer firewall models have more resources than older models.
Transaction sizes affect performance. Measure the average transaction size of all traffic, then
measure the average transaction size of traffic on port 443 (default port for HTTPS encrypted traffic)
to understand the proportion of encrypted traffic on the firewall in relation to your total traffic and
the average transaction sizes.
The combination of these factors determines how decryption consumes firewall processing resources. If
firewall resources are an issue, use stronger decryption for higher-priority and higher-risk traffic and use
less processor-intensive decryption to decrypt and inspect lower-priority traffic until you can increase
the available resources.
Size the firewall to include headroom for growth in the amount of traffic to decrypt because more traffic
is encrypted every day.

STEP 5 | Plan a staged, prioritized deployment.

Identify early adopters to champion decryption and get department managers on-board with the
plan.
Set up POCs to test the deployment strategy before you roll it out to the general user population.
Measure the way the decryption POC deployment affects firewall CPU and memory utilization to
help understand if firewall sizing is correct. POCs can also reveal applications that break decryption
technically.
• Educate POC participants on the changes and how to contact technical support.
• Set up a technical support POC for the decryption POCs so that support has the opportunity to
develop the best ways to support the rollout.
• Phase in decryption. Plan to decrypt the riskiest traffic first (URL Categories most likely to harbor
malicious traffic, such as gaming or high-risk) and then decrypt more as you gain experience.
Alternatively, decrypt the URL Categories that don’t affect your business first (if something
goes wrong, it won’t affect business), for example, news feeds. In both cases, decrypt a few
URL Categories, listen to user feedback, run reports and check Decryption logs to ensure that
decryption is working as expected, and then gradually decrypt a few more URL Categories, etc.
Plan to make decryption exclusions to exclude sites from decryption if you can’t decrypt them for
technical reasons or because you choose not to decrypt them.
• Gauge the success of the POCs and fine-tune deployment practices.
Educate the user population before the general rollout. POCs help identify the most important points
to communicate.
Distribute updated legal and HR computer usage policies to all employees, contractors, partners,
guests, and any other network users. Ensure that everyone understands their data can be decrypted
and scanned for threats as you roll out decryption to each department or group.
Create realistic schedules that allow time to evaluate each stage of the rollout.

DECRYPTION BEST PRACTICES | Decryption Best Practices 9

© 2020 Palo Alto Networks, Inc.
Deploy SSL Decryption Using Best Practices
STEP 1 | 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, 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.

STEP 2 | 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

10 DECRYPTION BEST PRACTICES | Decryption Best Practices

© 2020 Palo Alto Networks, Inc.
 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.

STEP 3 | 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.
Configure decryption logging and log forwarding.
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.

STEP 4 | 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.)

STEP 5 | 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. 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.

DECRYPTION BEST PRACTICES | Decryption Best Practices 11

© 2020 Palo Alto Networks, Inc.
STEP 6 | Forward decrypted traffic to WildFire to inspect it for malware.

STEP 7 | 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.

12 DECRYPTION BEST PRACTICES | Decryption Best Practices

© 2020 Palo Alto Networks, Inc.
Follow Post-Deployment SSL Decryption Best
Practices
After you deploy decryption, ensure that everything is working as expected and take steps to ensure that it
keeps working as expected.

STEP 1 | Verify that decryption works as expected.

STEP 2 | Measure firewall performance to ensure that it’s within acceptable norms and so that you
understand the effect of decryption on performance.
If you want to decrypt more traffic than firewall resources support, scale up so that you have enough
resources to decrypt all of the traffic you want to decrypt and secure your network.

STEP 3 | Educate new employees as you hire them so that they understand your decryption policy and
won’t be surprised if they can’t reach a particular site because it uses weak cipher suites.

STEP 4 | Periodically review and update Decryption policies and profiles.

STEP 5 | Use decryption troubleshooting tools such as the Application Command Center’s SSL Activity
widgets and the Decryption log (Monitor > Logs > Decryption) to monitor decryption traffic
and solve decryption issues.
Decryption troubleshooting workflow examples show you how to use the tools to investigate issues.

STEP 6 | Use Palo Alto Networks documentation and other resources to learn more about Decryption
and to look up information:
• The PAN-OS Administrator’s Guide provides detailed information about Palo Alto Networks next-
generation firewalls.
• Palo Alto Networks Live community has a Decryption Resource List of articles about decryption
configuration, setup, and administration.
• To find missing intermediate certificates, visit SSL Labs (Qualys).
• To find out which cipher suites a server supports, visit Qualys SSL Labs server SSL test page.
• To check up-to-date statistics on the percentages of different ciphers and protocols in use on the
150,000 most popular sites in the world so you can see trends and understand how widespread
worldwide support is for more secure ciphers and protocols, visit Qualys SSL Labs SSL Pulse page.

DECRYPTION BEST PRACTICES | Decryption Best Practices 13

© 2020 Palo Alto Networks, Inc.
14 DECRYPTION BEST PRACTICES | Decryption Best Practices