Decrypon Best Pracces

Version 10.1

[Link]
 Contact Informaon
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
[Link]/company/[Link]

About the Documentaon

• For the most recent version of this guide or for access to related documentaon, visit the
Technical Documentaon portal [Link].
• To search for a specific topic, go to our search page [Link]/[Link].
• Have feedback or quesons for us? Leave a comment on any page in the portal, or write to us
at documentaon@[Link].

Copyright
Palo Alto Networks, Inc.
[Link]
©2021 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto
Networks. A list of our trademarks can be found at [Link]/company/
[Link]. All other marks menoned herein may be trademarks of their respecve
companies.

Last Revised
February 5, 2021

Decrypon Best Pracces Version Version 10.1 2 ©2021 Palo Alto Networks, Inc.
Table of Contents
Decrypon Best Pracces................................................................................5
Plan Your SSL Decrypon Best Pracce Deployment........................................................ 6
Deploy SSL Decrypon Using Best Pracces.....................................................................11
Follow Post-Deployment SSL Decrypon Best Pracces................................................14

Decrypon Best Pracces Version Version 10.1 3 ©2021 Palo Alto Networks, Inc.
Table of Contents

Decrypon Best Pracces Version Version 10.1 4 ©2021 Palo Alto Networks, Inc.
Decrypon Best Pracces
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 encrypon. Google’s Transparency Report shows that no maer 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 pracces that you can follow to implement decrypon. Each secon
includes links to detailed informaon in the PAN-OS Admin Guide, including how to
configure Decrypon policy rules and profiles.

> Plan Your SSL Decrypon Best Pracce Deployment

> Deploy SSL Decrypon Using Best Pracces
> Follow Post-Deployment SSL Decrypon Best Pracces

5
Decrypon Best Pracces

Plan Your SSL Decrypon Best Pracce Deployment

Prepare to deploy decrypon by developing a decrypon strategy and roll-out plan. Turning on
decrypon may change the way users interact with some applicaons and websites, so planning,
tesng, and user educaon are crical to a successful deployment.
STEP 1 | Set goals.
Plan to decrypt as much traffic that is not private or sensive as your firewall resources
permit. This reduces the aack surface by exposing and prevenng encrypted threats.
Understand local laws and regulaons about the traffic you can legally decrypt and user
noficaon requirements.
Migrate from port-based to applicaon-based Security policy rules before you create and
deploy Decrypon policy rules. If you create Decrypon rules based on port-based Security
policy and then migrate to applicaon-based Security policy, the change could cause the
Decrypon rules to block traffic that you intend to allow because Security policy rules are
likely to use applicaon default ports to prevent traffic from using non-standard ports.
Migrang to App-ID based rules before deploying decrypon ensures that when you test
your decrypon deployment, you’ll discover Security policy misconfiguraons and fix them
before rolling decrypon out to the general user populaon.

Decrypon Best Pracces Version Version 10.1 6 ©2021 Palo Alto Networks, Inc.
Decrypon Best Pracces

STEP 2 | Work with and educate stakeholders such as legal, finance, HR, execuves, security, and IT/
support to develop a decrypon deployment strategy.
Get the required approvals to decrypt traffic to secure the enterprise.
Idenfy and priorize the traffic to decrypt:
• Decide which applicaons to decrypt (sanconed, unsanconed). Don’t allow encrypted
unsanconed applicaons.
• 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 Authencaon Portal, instruct them how to download and install the CA
cerficate, and clearly nofy 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 decrypon policy for different groups, such as
different employee groups, contractors, partners, and guests.
Idenfy traffic you can’t decrypt:
• Traffic that breaks decrypon for technical reasons such as cerficate pinning,
unsupported ciphers, or mutual authencaon.
• Traffic that you choose not to decrypt such as financial, health, government, and other
sensive categories, including users and groups such as execuves.
• Fully understand the traffic you except from decrypon. You don’t have visibility into
encrypted traffic and the firewall can’t apply threat prevenon 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
decrypon, users understand their data can be decrypted and scanned for threats.
Decide how to handle cerficate verificaon. Your business model may require tradeoffs
between security and the user experience. Understanding how you want to handle
cerficate verificaon helps determine how you configure SSL Forward Proxy Decrypon
profiles.
Idenfy 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 exisng PKI, generate the SSL Forward Trust CA cerficate from your
Enterprise Root CA as a subordinate cerficate. This makes deployment easier because

Decrypon Best Pracces Version Version 10.1 7 ©2021 Palo Alto Networks, Inc.
Decrypon Best Pracces

network devices already trust the Enterprise Root CA, so you won’t run into cerficate
issues. If you don’t have an Enterprise Root CA, consider geng one.
Alternavely, generate a self-signed Root CA cerficate on the firewall and create a
subordinate Forward Trust CA cerficate on that firewall to install on network devices. Self-
signed cerficates 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 Authencaon Portal, instruct them how to download and install the CA
cerficate, and clearly nofy users that their traffic will be decrypted. Include the
process in your company’s privacy and computer usage policy.
Generate separate CA cerficates for Forward Trust and Forward Untrust. Do not use
the same PKI subordinate CA for both cerficates and do not sign the Forward Untrust
cerficate with the Trusted Root CA! The Forward Untrust cerficate warns users that the
cerficate signing the server is not legimate and that they should not proceed to the site. If
the Trusted Root CA signs the Untrust cerficate, then clients trust cerficates that should
be untrusted because clients trust the Root CA.
Generate a separate subordinate Forward Trust CA cerficate for each firewall. Using
separate subordinate CAs enables you to revoke a cerficate when you decommission
a device (or device pair) without affecng the rest of the deployment and reduces the
impact if you need to revoke a cerficate. Separate CA cerficates help technical support
troubleshoot user issues because the cerficate error message includes informaon about
the firewall the traffic traversed. Although using one Forward Trust subordinate CA on all
firewalls is easier to deploy, using a separate cerficate on each firewall provides the best
security.
If you need addional security for your private keys, consider storing them in an HSM.

STEP 4 | Take a baseline measurement of firewall performance to understand resource consumpon

and available firewall resources so that you can compare performance aer you deploy
decrypon and esmate 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 ghter your security, the
more resources decrypon 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 aacker

Decrypon Best Pracces Version Version 10.1 8 ©2021 Palo Alto Networks, Inc.
Decrypon Best Pracces

compromises a session key, PFS prevents the aacker from using it to decrypt other
sessions between the same client and server, while RSA does not.
• Cerficate authencaon. RSA cerficate authencaon (this is not the same as the
RSA key exchange algorithm) consumes fewer CPU cycles than ECDSA cerficate
authencaon but ECDSA provides the highest level of security.
• Encrypon algorithm. The key exchange algorithm determines whether the encrypon
algorithm is PFS or RSA.
• The firewall model and resources. Newer firewall models have more resources than older
models.
Transacon sizes affect performance. Measure the average transacon size of all traffic,
then measure the average transacon size of traffic on port 443 (default port for HTTPS
encrypted traffic) to understand the proporon of encrypted traffic on the firewall in
relaon to your total traffic and the average transacon sizes.
The combinaon of these factors determines how decrypon consumes firewall processing
resources. If firewall resources are an issue, use stronger decrypon for higher-priority and
higher-risk traffic and use less processor-intensive decrypon to decrypt and inspect lower-
priority traffic unl 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, priorized deployment.

Idenfy early adopters to champion decrypon 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
populaon. Measure the way the decrypon POC deployment affects firewall CPU and
memory ulizaon to help understand if firewall sizing is correct. POCs can also reveal
applicaons that break decrypon technically.
• Educate POC parcipants on the changes and how to contact technical support.
• Set up a technical support POC for the decrypon POCs so that support has the
opportunity to develop the best ways to support the rollout.
• Phase in decrypon. 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. Alternavely, 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 Decrypon logs to ensure that decrypon is working as expected, and then
gradually decrypt a few more URL Categories, etc. Plan to make decrypon exclusions to
exclude sites from decrypon 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 pracces.
Educate the user populaon before the general rollout. POCs help idenfy 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

Decrypon Best Pracces Version Version 10.1 9 ©2021 Palo Alto Networks, Inc.
Decrypon Best Pracces

can be decrypted and scanned for threats as you roll out decrypon to each department or
group.
Create realisc schedules that allow me to evaluate each stage of the rollout.

Decrypon Best Pracces Version Version 10.1 10 ©2021 Palo Alto Networks, Inc.
Decrypon Best Pracces

Deploy SSL Decrypon Using Best Pracces

STEP 1 | Generate and distribute keys and cerficates for Decrypon policies.
If you have an Enterprise PKI, generate the Forward Trust CA cerficate for forward proxy
traffic from your Enterprise Root CA. Otherwise, generate a self-signed Root CA cerficate
on the firewall, create a subordinate CA on that firewall, and then distribute the self-signed
cerficate to all client systems. Self-signed cerficates are intended for lab tesng, 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 cerficate is easier to deploy, but separate
cerficates provide the best security and other benefits). Different PKI plaorms have
different features for scaling cerficate management.
If you do not use an Enterprise CA, import the Forward Trust CA cerficate into the client
systems’ trust CA storage.
Do not import the Forward Untrust CA cerficate into the CA trust storage on client
systems or the untrust cerficate 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 cerficate.)
Use an automated method to distribute the Forward Trust cerficates to connected devices,
such as the Palo Alto Networks GlobalProtect Portal, Microso AD Cerficate Services
(using Group Policy Objects), commercial tools, or open source tools.
If you generate the cerficate from your Enterprise Root CA, import the cerficate on the
firewall.
Back up the private key for the firewall’s Forward Trust CA cerficate (not the firewall’s
master key) in a secure repository so that if an issue occurs, you can sll access the Forward
Trust CA cerficate.
If you generate cerficates 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 Decrypon profiles to control protocols, cerficate verificaon, and failure
handling.
SSL Forward Proxy Decrypon profiles control server cerficate verificaon, session modes,
and failure checks for outbound traffic. Block sessions with expired cerficates, untrusted
issuers, unsupported versions, and unsupported cipher suites. Block sessions with client
authencaon unless an important applicaon requires it, in which case you should create a
separate Decrypon profile that allows client authencaon and apply it only to traffic that
requires client authencaon.
SSL Inbound Inspecon Decrypon profiles control session modes and failure checks for
inbound traffic. Block sessions with unsupported versions and unsupported cipher suites.
SSL Protocol Sengs control cipher suite elements: protocol versions, key exchange
algorithms, encrypon algorithms, and authencaon algorithms for SSL Forward Proxy
and SSL Inbound Inspecon traffic. Use the strongest ciphers that you can. For Forward

Decrypon Best Pracces Version Version 10.1 11 ©2021 Palo Alto Networks, Inc.
Decrypon Best Pracces

Proxy, set the protocol Min Version to TLSv1.2 and the Max Version to Max to block weak
protocols. For SSL Inbound Inspecon, create separate profiles with protocol sengs that
match the capabilies of the server(s) whose inbound traffic you are inspecng.

Use the strongest cipher suite that you can. Create separate Decrypon policies
and profiles to maximize security. If legacy sites that you need for business purposes
only support weaker ciphers, create a separate Decrypon profile to allow the that
traffic and apply it in a Decrypon policy only to the necessary sites. Use the same
technique to fine tune security vs. performance for different URL categories.
Many mobile applicaons use pinned cerficates. Because TLSv1.3 encrypts
cerficate informaon, the firewall can’t automacally add these mobile
applicaons to the SSL Decrypon Exclusion List. For these applicaons, ensure
that the Decrypon profile Max Version is set to TLSv1.2 or apply a No Decrypon
policy to the traffic.
No Decrypon profiles control server cerficate verificaon for traffic you choose not to
decrypt. Block sessions with expired cerficates and untrusted issuers.

Do not apply a No Decrypon profile to TLSv1.3 traffic. The cerficate informaon

is encrypted, so the firewall cannot block sessions based on cerficate informaon.
For SSL Forward Proxy and No Decrypon traffic, configure both Cerficate Revocaon
List (CRL) and Online Cerficate Status Revocaon (OCSP) cerficate revocaon checks to
verify that site cerficates 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 pracce Decrypon profile sengs for the data center and for the perimeter
(internet gateway) use cases differ slightly from the general best pracce sengs.

STEP 3 | Configure Decrypon policy rules to define the traffic to decrypt and to make policy-based
excepons for traffic you choose not to decrypt.
Create policy rules to except specific desnaon IP addresses (for example, finance servers),
source users and groups (for example, execuves or HR personnel), source devices, and
applicaon ports that you choose not to decrypt. Place these rules at the top of the
Decrypon rulebase, before rules that decrypt traffic. For all traffic except TLSv1.3 traffic,
aach a No Decrypon profile to them to apply SSL server cerficate verificaon controls
to the encrypted traffic. This prevents inadvertently decrypng 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

Decrypon Best Pracces Version Version 10.1 12 ©2021 Palo Alto Networks, Inc.
Decrypon Best Pracces

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 Decrypon policy rule for them.
Place these rules above rules that decrypt traffic in the Decrypon rulebase.
Configure decrypon logging and log forwarding.
If you use Decrypon mirroring to copy and send decrypted traffic to a traffic collecon
tool, be aware of local privacy regulaons 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 Inspecon, and SSH Proxy rules. Always decrypt the online-storage-and-backup,
web-based-email, web-hosng, 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 Mul-Factor Authencaon to prevent unauthorized SSH
access.

STEP 4 | Add sites to the SSL Decrypon Exclusion list (Device > Cerficate Management > SSL
Decrypon Exclusion) if they break decrypon technically during POC tesng and are not
already on the exclusion list. (Decrypng sites that block decrypon technically results in
blocking that traffic.)

STEP 5 | In Security policy, block Quick UDP Internet Connecons (QUIC) protocol.
Chrome and some other browsers establish sessions using QUIC instead of TLS, but QUIC
uses proprietary encrypon that the firewall can’t decrypt, so potenally dangerous traffic may
enter the network as encrypted traffic. Create two rules, one to block the QUIC applicaon on
standard ports and one to block UDP ports 80 and 443. Blocking QUIC forces the browser to
use TLS.

STEP 6 | Forward decrypted traffic to WildFire to inspect it for malware.

STEP 7 | Roll out decrypon slowly.

Decrypt a few URL Categories, review user feedback, and run reports to ensure that
decrypon works as expected. Gradually decrypt more URL Categories unl 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 conservave alternave is to decrypt URL Categories that don’t affect your business
first, for example, news feeds.

Decrypon Best Pracces Version Version 10.1 13 ©2021 Palo Alto Networks, Inc.
Decrypon Best Pracces

Follow Post-Deployment SSL Decrypon Best Pracces

Aer you deploy decrypon, ensure that everything is working as expected and take steps to
ensure that it keeps working as expected.
STEP 1 | Verify that decrypon works as expected.

STEP 2 | Measure firewall performance to ensure that it’s within acceptable norms and so that you
understand the effect of decrypon 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 decrypon policy and
won’t be surprised if they can’t reach a parcular site because it uses weak cipher suites.

STEP 4 | Periodically review and update Decrypon policies and profiles.

STEP 5 | Use decrypon troubleshoong tools such as the Applicaon Command Center’s SSL
Acvity widgets and the Decrypon log (Monitor > Logs > Decrypon) to monitor
decrypon traffic and solve decrypon issues.
Decrypon troubleshoong workflow examples show you how to use the tools to invesgate
issues.

STEP 6 | Use Palo Alto Networks documentaon and other resources to learn more about Decrypon
and to look up informaon:
• The PAN-OS Administrator’s Guide provides detailed informaon about Palo Alto Networks
next-generaon firewalls.
• Palo Alto Networks Live community has a Decrypon Resource List of arcles about
decrypon configuraon, setup, and administraon.
• To find missing intermediate cerficates, 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 stascs 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.

Decrypon Best Pracces Version Version 10.1 14 ©2021 Palo Alto Networks, Inc.