Network Security
Decryption Profiles
Table of Contents
Expand All
|
Collapse All
Network Security Docs
-
- Security Policy
-
- Security Profile Groups
- Security Profile: AI Security
- Security Profile: WildFire® Analysis
- Security Profile: Antivirus
- Security Profile: Vulnerability Protection
- Security Profile: Anti-Spyware
- Security Profile: DNS Security
- Security Profile: DoS Protection Profile
- Security Profile: File Blocking
- Security Profile: URL Filtering
- Security Profile: Data Filtering
- Security Profile: Zone Protection
-
- Policy Object: Address Groups
- Policy Object: Regions
- Policy Object: Traffic Objects
- Policy Object: Applications
- Policy Object: Application Groups
- Policy Object: Application Filter
- Policy Object: Services
- Policy Object: Auto-Tag Actions
- Policy Object: Devices
-
- Uses for External Dynamic Lists in Policy
- Formatting Guidelines for an External Dynamic List
- Built-in External Dynamic Lists
- Configure Your Environment to Access an External Dynamic List
- Configure your Environment to Access an External Dynamic List from the EDL Hosting Service
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Policy Object: HIP Objects
- Policy Object: Schedules
- Policy Object: Quarantine Device Lists
- Policy Object: Dynamic User Groups
- Policy Object: Custom Objects
- Policy Object: Log Forwarding
- Policy Object: Authentication
- Policy Object: Decryption Profile
- Policy Object: Packet Broker Profile
-
-
-
- The Quantum Computing Threat
- How RFC 8784 Resists Quantum Computing Threats
- How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
- Support for Post-Quantum Features
- Post-Quantum Migration Planning and Preparation
- Best Practices for Resisting Post-Quantum Attacks
- Learn More About Post-Quantum Security
-
-
-
- Investigate Reasons for Decryption Failure
- Identify Weak Protocols and Cipher Suites
- Troubleshoot Version Errors
- Troubleshoot Unsupported Cipher Suites
- Identify Untrusted CA Certificates
- Repair Incomplete Certificate Chains
- Troubleshoot Pinned Certificates
- Troubleshoot Expired Certificates
- Troubleshoot Revoked Certificates
Decryption Profiles
Decryption profiles control SSL/TLS and SSH connection settings, such as protocol
versions, server certificate, and other checks for traffic matching decryption
rules.
Where Can I Use This? | What Do I Need? |
---|---|
|
No requirements.
|
Decryption profiles enable you to perform certificate verification checks, session mode
checks, failure checks, and protocol and algorithm checks on SSL/TLS and SSH traffic
that you decrypt or exclude from decryption. These checks prevent
risky connections, such as sessions with certificate issues, weak protocols, or weak
algorithms. The NGFW enforces the profile settings on traffic matching
the conditions of a decryption policy rule. After you create a decryption profile,
associate it with a decryption policy rule to activate the profile settings.
You can create decryption profiles to:
- Define the protocol versions and key exchange, encryption, and authentication algorithms allowed for SSL Forward Proxy and SSL Inbound Inspection traffic
- Block sessions based on certificate status, including blocking sessions with expired certificates, untrusted issuers, unknown certificate status, certificate status check timeouts, and certificate extensions
- Block sessions with unsupported versions or cipher suites or that require using client authentication
- Block sessions if the resources to perform decryption are not available or if a hardware security module (HSM) is not available to sign certificates
The settings available in a profile differ based on the type of
profile you create. For example, some unsupported mode check settings are not available
in different profiles.
You can create distinct decryption profiles for SSL Forward Proxy, SSL Inbound
Inspection, and SSH Proxy. You can even associate
no-decryption profiles
with
no-decryption policy rules controlling traffic that you choose not to decrypt
because the traffic is personal, sensitive, or subject to local laws and regulations.
For example, you might not decrypt the traffic of certain executives or traffic between
finance users and finance servers that contain personal information.Avoid excluding traffic that breaks decryption for
technical reasons such as a pinned certificate or mutual authentication by policy.
Instead, add the hostname to the Decryption Exclusion List.
- Apply ano-decryption profileto decryption policy rules for undecrypted traffic to block sessions with expired certificates and untrusted issuers.
- Enable the tighter decryption controls described in the following sections:
Decryption Profile: SSL Decryption,Decryption Profile: No Decryption, andDecryption Profile: SSH Proxy.
You can also use the default decryption profile, which enforces the basic recommended
protocol versions and cipher suites for decrypted traffic.
If you must allow any categories that we suggest you block for business reasons, decrypt
them and apply strict security profiles to the traffic.
Don’t weaken the main decryption profile that
you apply to most sites to accommodate weaker sites. Instead, create one or more
separate decryption profiles for sites that you need to support but that don’t support
strong ciphers and algorithms. You can also create different decryption profiles for
different URL categories to fine-tune security versus performance for traffic that
contains no sensitive material; however, you should always decrypt and inspect all the
traffic you can.
Summary of Decryption Profile Settings
The settings available in a profile differ based on the type
of profile you create. For example, some unsupported mode check settings are not
available in different profiles.
- Unsupported mode checks Blocking these sessions protects you from servers that use weak, risky protocol versions and algorithms. If you don’t block sessions with unsupported modes, users receive a warning message if they connect with potentially unsafe servers. They can click through the warning to access the potentially dangerous site.
- Block sessions with client authenticationIf you have no critical applications that require client authentication, select this option. The NGFW can’t decrypt sessions that require client authentication. The NGFW needs both the client and the server certificates to perform bidirectional decryption, but with client authentication, the NGFW only knows the server certificate. This breaks decryption for client authentication sessions. When you select this option, the NGFW blocks all sessions with client authentication except sessions from sites on the SSL decryption exclusion list.If you don’t block sessions that require client authentication, the NGFW allows the session when it attempts decryption and adds an entry containing the URL or IP address of the server, the application, and corresponding decryption profile to its Local SSL Decryption Exclusion Cache.
- Block sessions with unsupported cipher suitesThis option blocks sessions if the NGFW doesn’t support the cipher suite specified in the handshake. You can configure which algorithms the NGFW supports on the SSL Protocol Settings tab of the decryption profile.
- (SSH Proxy) Block sessions with unsupported algorithms
- Block sessions with unsupported versionsThis option blocks sessions with the weak SSL/TLS protocol versions that you have chosen not to support. You can specify the minimum SSL/TLS protocol version to allow on your network in theSSL Protocol Settingsof a decryption profile, and reduce the attack surface by blocking weak protocols.
Expand all
Collapse all
- Failure Checks
- Block sessions if resources not availableIf you select this option, the NGFW drops traffic when it doesn’t have the resources to decrypt the traffic. If you don’t block sessions when the NGFW can’t process decryption due to a lack of resources, then traffic that you want to decrypt enters the network encrypted and is not inspected. However, blocking sessions when resources aren’t available may affect the user experience by making sites that users normally can reach temporarily unreachable. Whether to implement this failure check depends on your company’s security compliance stance and the importance of the user experience, weighed against tighter security. Alternatively, consider using NGFW models with more processing power so that you can decrypt more traffic.
- Block sessions if HSM not availableIf you use an HSM to store private keys, consider your compliance rules about where the private key must come from and how you want to handle encrypted traffic if the HSM isn’t available. For example, if your company mandates the use of an HSM for private key signing, then block sessions if the HSM isn’t available. However, if your company is less strict about this, don't block sessions if the HSM isn’t available. (If the HSM is down, the NGFW can process decryption for sites for which it has cached the response from the HSM, but not for other sites.) The best practice in this case depends on your company’s policies. If the HSM is critical to your business, run the HSM in a high availability (HA) pair.
- Block downgrade on no resourcePrevents the NGFW from downgrading TLSv1.3 to TLSv1.2 if the NGFW has no available TLSv1.3 processing resources. If you block the downgrade, then when the NGFW runs out of TLSv1.3 resources, it drops traffic that uses TLSv1.3 instead of downgrading it to TLSv1.2. If you don’t block the downgrade, then when the NGFW runs out of TLSv1.3 resources, it downgrades to TLSv1.2. However, blocking downgrade when resources aren’t available may affect the user experience by making sites that users normally can reach temporarily unreachable. Whether to implement this failure check depends on your company’s security compliance stance and the importance of the user experience, weighed against tighter security. You may want to create a separate decryption policy rule and profile to govern decryption for sensitive traffic for which you don’t want to downgrade the TLS version.
- Block sessions on SSH errors
Expand all
Collapse all
- Server Certificate Verification
- Block sessions with expired certificatesThis option blocks sessions with servers that have expired certificates and prevent access to potentially insecure sites. If you don’t check this box, users can connect with and transact with potentially malicious sites and see warning messages when they attempt to connect, but the connection is not prevented.
- Block sessions with untrusted issuersThis option blocks sessions with servers that have untrusted certificate issuers. An untrusted issuer may indicate a man-in-the-middle attack, a replay attack, or other attack.
- Block sessions with unknown certificate statusThis option blocks an SSL/TLS session when the certificate revocation status of the server returns a status of "unknown." Because certificate status may be unknown for multiple reasons, for general decryption security, checking this box usually tightens security too much. However, in higher-security areas of the network such as the data center, checking this box makes sense.
- Block sessions on SNI mismatch with Server Certificate (SAN/CN)Automatically deny any sessions where the Server Name Indication (SNI) does not match the server certificate. Palo Alto Networks recommends enabling this option if you configure an explicit proxy or transparent proxy. For more information, refer to Configure a Web Proxy in the PAN-OS Networking Administrator's Guide.
- Block sessions on certificate status check timeoutWhether to block sessions if the status check times out depends on your company’s security compliance stance because it’s a tradeoff between tighter security and a better user experience. Certificate status verification examines the certificate revocation list (CRL) on a revocation server or uses the Online Certificate Status Protocol (OCSP) to find out if the issuing CA has revoked the certificate and the certificate should not be trusted. However, revocation servers can be slow to respond, which can cause the session to time out and the NGFW to block the session even though the certificate may be valid.If you enable this setting and the revocation server is slow to respond, you can configure the Certificate Revocation Checking setting to change the default timeout value of 5 seconds to another value. For example, you could increase the timeout value to 8 seconds, as shown in the following figure. Enable both CRL and OCSP certificate revocation checking because server certificates can contain the CRL URL in the CRL Distribution Point (CDP) extension or the OCSP URL in the Authority Information Access (AIA) certificate extension.
- Restrict certificate extensionsThis option limits the certificate extensions in the server certificate to key usage and extended key usage and blocks certificates with other extensions. However, in certain deployments, some other certificate extensions may be necessary, so only check this box if your deployment requires no other certificate extensions.
- Append certificate’s CN value to SAN extensionThis option ensures that when a browser requires a server certificate to use a Subject Alternative Name (SAN) and doesn’t support certificate matching based on the Common Name (CN), if the certificate doesn’t have a SAN extension, users can still access the requested web resources because the NGFW adds the SAN extension (based on the CN) to the impersonation certificate.
Expand all
Collapse all
The following table lists the profile types and the settings that they apply to.
Settings | Profile Types | ||||
---|---|---|---|---|---|
SSL Forward Proxy | SSL Inbound Inspection | SSH Proxy | No Decryption | ||
Server Certificate Verification | Block sessions with expired certificates | Yes | No | No | Yes |
Block sessions with untrusted issuers | Yes | No | No | Yes | |
Block sessions with unknown certificate status | Yes | No | No | No | |
Block sessions on SNI mismatch with Server Certificate (SAN/CN) | Yes | No | No | No | |
Block sessions on certificate status check timeout | Yes | No | No | No | |
Restrict certificate extensions | Yes | No | No | No | |
Append certificate’s CN value to SAN extension | Yes | No | No | No | |
Unsupported Mode Checks | Block sessions with unsupported versions | Yes | Yes | Yes | No |
Block sessions with unsupported cipher suites | Yes | Yes | Yes | No | |
Block sessions with unsupported algorithms | No | No | Yes | No | |
Block sessions with client authentication | Yes | No | No | No | |
Failure Checks | Block sessions if resources not available | Yes | Yes | Yes | No |
Block sessions if HSM not available | Yes | Yes | No | No | |
Block downgrade on no resource | Yes | Yes | No | No | |
Block sessions on SSH errors | No | No | Yes | No |
Decryption Profile: SSL Decryption
The SSL Decryption tab manages profiles for SSL Forward Proxy and SSL Inbound
Inspection and the SSL Protocol Settings (Protocol Versions, Key Exchange
Algorithms, Encryption Algorithms, and Authentication Algorithms), which apply to
both profile types. There are settings for Server Certificate Verification,
Unsupported Mode Checks, Failure Checks, and Client Extensions. SSL Forward Proxy
and SSL Inbound Inspection share some settings, but only the SSL Forward Proxy
profile has options for server certificate verification.
You may need to allow traffic on your network from sites that use client
authentication and are not in the predefined sites on the SSL decryption
exclusion list. Create a decryption profile that allows sessions with client
authentication. Add it to a decryption policy rule that applies only to the
servers that host the application. To increase security even more, you can
require multi-factor authentication to complete the user login process.
The following concepts summarize the profile settings and recommendations for each
profile type: SSL Forward Proxy and SSL Inbound Inspection, No decryption, and SSH
Proxy. Select a profile type to learn more about the unique settings and
recommendations offered.
- SSL Forward Proxy
- SSL Inbound Inspection
- SSL Protocol Settings
SSL Forward Proxy
The SSL Forward Proxy decryption profile controls server verification, session
mode checks, and failure checks for outbound SSL and TLS traffic defined in the
Forward Proxy decryption policy rules to which you attach the profile.
SSL Forward Proxy can't decrypt some sessions, such as sessions with client
authentication or pinned certificates because the NGFW is a
proxy device. Being a proxy also means that the NGFW does not
support high availability (HA) sync for decrypted SSL sessions.
The following figure shows the general best practice recommendations for SSL
Forward Proxy decryption profiles, but the settings you use also depend on your
company’s security compliance rules and local laws and regulations. There are
also specific best practices for perimeter internet gateway decryption profiles
and for data center decryption profiles.

SSL Inbound Inspection
The SSL Inbound Inspection decryption profile controls the session mode checks
and failure checks for inbound SSL/TLS traffic defined in the Inbound Inspection
decryption policy rules to which you attach the profile. The following figure
shows the general best practice recommendations for Inbound Inspection
decryption profiles, but the settings you use also depend on your company’s
security compliance rules and local laws and regulations.
SSL Inbound Inspection can't decrypt some sessions, such as sessions with
client authentication or pinned certificates, because the NGFW is a proxy device. Being a proxy also means that the NGFW
does not support high availability (HA) sync for decrypted SSL sessions.

SSL Protocol Settings
The SSL Protocol Settings tab controls the cipher suites—the protocol versions,
key exchange algorithms, encryption algorithms, and authentication
algorithms–used for SSL Forward Proxy and SSL Inbound Inspection traffic. You
can decide whether to allow vulnerable or weak SSL/TLS protocol versions,
encryption algorithms, and authentication algorithms. SSL Protocol Settings
apply to outbound SSL Forward Proxy traffic and inbound SSL Inbound Inspection
traffic. These settings don’t apply to SSH Proxy traffic or to traffic that you
don’t decrypt.
Protocol Versions: Specify the minimum and maximum TLS versions that you'd
like to support for decryption.
- Set the Min Version to TLSv1.3 to provide the strongest security. Business sites that value security support TLSv1.3. If a site (or a category of sites) only supports weaker ciphers, review the site and determine if it hosts a legitimate business application. If it does, make an exception for only that site by configuring a decryption profile with a Min Version that matches the strongest cipher the site supports and then applying the profile to a decryption policy rule that limits allowing the weak cipher to only the site or sites in question. If the site doesn’t host a legitimate business application, don’t weaken your security posture to support the site. Weak protocols (and ciphers) contain known vulnerabilities that attackers can exploit.If the site belongs to a category of sites that you don’t need for business purposes, use URL filtering to block access to the entire category. Don’t support weak encryption or authentication algorithms unless you must support important legacy sites, and when you make exceptions, create a separate decryption profile that allows the weaker protocol just for those sites. Don’t downgrade the main decryption profile that you apply to most sites to TLSv1.1 just to accommodate a few exceptions.Qualys SSL Labs SSL Pulse web page provides 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.
- Set the Max Version to Max rather than to a particular version so that as the protocols improve, the NGFW or Prisma Access automatically supports the newest and best protocols. Whether you intend to attach a decryption profile to a decryption policy rule that governs inbound (SSL Inbound Inspection) or outbound (SSL Forward Proxy) traffic, avoid allowing weak algorithms.If your decryption policy supports mobile applications, many of which use pinned certificates, set the Max Version to TLSv1.2. Because TLSv1.3 encrypts certificate information that wasn’t encrypted in previous TLS versions, the NGFW can’t automatically add decryption exclusions based on certificate information, which affects some mobile applications. Therefore, if you enable TLSv1.3, the NGFW may drop some mobile application traffic unless you create a no-decryption policy rule for that traffic.If you know the mobile applications you use for business, consider creating a separate decryption policy rule and profile for those applications so that you can enable TLSv1.3 for all other application traffic.
The following figure shows the general best practice recommendations for SSL
Protocol Settings. There are also specific best practices for perimeter internet gateway decryption profiles
and for data center decryption profiles.
When you configure SSL Protocol Settings for SSL Inbound Inspection traffic,
create separate profiles for servers with different security capabilities.
For example, if one set of servers supports only RSA, the SSL Protocol
Settings only need to support RSA. However, the SSL Protocol Settings for
servers that support PFS should support PFS. Configure SSL Protocol Settings
for the highest level of security that the target server you're protecting
supports, but check performance to ensure that the NGFW and
Prisma Access resources can handle the higher processing load that
higher security protocols and algorithms require.

Key Exchange Algorithms:
Leave all three boxes checked (default) to support both RSA and Perfect Forward Secrecy (PFS) (DHE and
ECDHE) key exchanges unless the minimum version is set to TLSv1.3, which only
supports ECDHE.
To support HTTP/2 traffic, leave the ECDHE box checked.
Encryption Algorithms:
- When you set the minimum protocol version to TLSv1.2, the older, weaker 3DES and RC4 algorithms are automatically unchecked (blocked).
- When you set the minimum protocol version to TLSv1.3, the 3DES, RC4, AES128-CBC, and AES256-CBC algorithms are automatically blocked.
For any traffic for which you must allow a weaker TLS protocol, create a separate
decryption profile and apply it only to traffic for that site, and deselect the
appropriate boxes to allow the algorithm. Allowing traffic that uses the 3DES or
RC4 algorithms exposes your network to excessive risk. If blocking 3DES or RC4
prevents you from accessing a site that you must use for business, create a
separate decryption profile and policy rule for that site. Don’t weaken
decryption for any other sites.
Authentication Algorithms: The NGFW automatically blocks
the older, weaker MD5 algorithm. When TLSv1.3 is the minimum version, the NGFW also blocks SHA1. Don’t allow MD5 authenticated traffic on
your network; SHA1 is the weakest authentication algorithm you should allow. If
no necessary sites use SHA1, block SHA1 traffic to further reduce the attack
surface.
Decryption Profile: No Decryption
No-decryption profiles perform server verification checks for traffic that you choose
not to decrypt for legal, compliance, personal, or other reasons. Attach a
no-decrypt profile to a no-decrypt decryption policy rule that defines the
traffic you want to exclude from decryption.
Don’t create policy rules to exclude traffic that
you can’t decrypt because a site breaks decryption for technical reasons such as a
pinned certificate or mutual authentication. Instead, add the hostname to the SSL decryption exclusion list.
The following figure shows the general best practice recommendations for a no-decrypt
profile, but the settings you use also depend on your company’s security compliance
rules and local laws and regulations.

Don’t attach a no-decryption profile to decryption policy rules for TLSv1.3
traffic that you don’t decrypt. Unlike previous versions, TLSv1.3 encrypts
certificate information, so the NGFW has no visibility into
certificate data and therefore can't block sessions with expired certificates or
untrusted issuers, so the profile has no effect. (The NGFW can
perform certificate checks with TLSv1.2 and earlier because those protocols
don’t encrypt certificate information and you should apply a no-decryption
profile to their traffic.)
However, you should create a decryption policy rule for TLSv1.3 traffic that you
don’t decrypt because the NGFW does not log undecrypted traffic
unless a decryption policy rule controls that traffic.
(Applies to TLSv1.2 and earlier) If you choose to allow sessions with
untrusted issuers (not recommended) and only Block sessions with
expired certificates, there is a scenario in which a session
with a trusted, expired issuer may be blocked inadvertently. When the NGFW certificate store contains a valid, self-signed trusted CA
and the server sends an expired CA in the certificate chain, the NGFW does not check its certificate store. Instead, it blocks the
session based on the expired CA when it should find the trusted, valid
alternative trust anchor and allow the session based on that trusted self-signed
certificate.
To avoid this scenario, select Block sessions with untrusted
issuers in addition to Block sessions with expired
certificates. This forces the NGFW to check its
certificate store, find the self-signed trusted CA, and allow the session.
Decryption Profile: SSH Proxy
The SSH Proxy decryption profile controls the session mode checks and failure checks
for SSH traffic defined in the SSH Proxy decryption policy rules to which you attach
the profile. The following figure shows the general best practice recommendations
for SSH Proxy decryption profiles, but the settings you use also depend on your
company’s security compliance rules and local laws and regulations.
NGFWs don’t perform content and threat inspection on SSH tunnels
(port forwarding). However, they distinguish between the SSH application and the
SSH-tunnel application. If the NGFW identifies SSH tunnels, it
blocks the tunneled traffic and restricts the traffic according to configured
Security policy rules.
