Decryption Basics

The  Transport Layer Security (TLS)  protocol, which evolved from the  Secure Sockets Layer (SSL) , and the  Secure Shell (SSH)  protocol secure communication between two entities, such as a web server and a client. While SSL/TLS typically secures web-based communications, SSH typically secures remote access to servers and devices. These protocols use public and private key cryptography to establish secure connections. They encrypt data in a way that renders it meaningless to any entity lacking the certificate and keys required to establish trust and decode the data. However, the privacy and integrity that encryption provides can be exploited. For example, suppose an attacker installs malware on an HTTPS website, and employees visit the site and unknowingly download malware. The malware can use the infected employee endpoint to move laterally through the network and compromise other systems. Thus, traffic should not be trusted automatically.

Decryption is the process of converting encrypted data into its original format, so that it's readable. This process allows for inspection and visibility into SSL/TLS and SSH traffic. You can decrypt both outbound and inbound traffic.  SSL Forward Proxy  inspects traffic exiting your internal network to the internet.  SSL Inbound Inspection  inspects traffic entering internal network servers.  SSH Proxy  inspects and controls traffic in SSH tunnels. Consider that you can’t block traffic that you don't inspect.

SSH Proxy isn’t supported by Strata Cloud Manager.

Decrypt SSL and SSH traffic to:

SSL decryption uses  keys and certificates  to establish a Next-Generation Firewall (NGFW) as a trusted third party between a client and a server. The NGFW decrypts SSL/TLS traffic to plaintext for inspection. Then, the NGFW re-encrypts the traffic before forwarding it to its destination, ensuring the privacy and security of the data. SSL decryption works with  Advanced Threat Prevention ,  Advanced URL Filtering , and other services that require packet inspection. Without SSL decryption, you couldn't  create exceptions to URL categories  for websites encrypted with HTTPS. It also provides additional use cases for these services. For example, you can selectively decrypt traffic based on URL categories and apply threat prevention controls.

SSH decryption does not require certificates. With SSH decryption enabled, an NGFW decrypts and blocks or restricts SSH traffic according to your decryption policy rules and profiles. It specifically tackles SSH tunneling. The NGFW also re-encrypts the SSH traffic as it exits. You can use  Decryption Port Mirroring  to forward decrypted traffic to a third-party solution for additional analysis and archiving. All mirrored traffic, including sensitive information, is forwarded in cleartext.

Be aware of local laws and regulations about what traffic you can mirror and where and how you can store the traffic. The use of SSL traffic is regulated in some countries and jurisdictions.

Palo Alto Networks decryption is policy-based. NGFWs handle encrypted traffic according to a  decryption policy . A decryption policy consists of one or more  decryption policy rules , which specify the traffic targeted for decrypted, the type of decryption performed, and how certain traffic is handled. Configure and associate a  decryption profile  with a decryption policy rule to define the protocol versions and cipher suites supported by the client (in the case of SSL decryption) or to configure certificate verification and other checks. For example, you can create a no-decryption policy rule and profile to bypass decryption of financial or healthcare data.

Decrypting all traffic indiscriminately can be resource-intensive. When  planning  for and implementing decryption, balance the need for thorough inspection with considerations of performance, compliance, security, and resource management. For example, if performance and sizing are major considerations, you might prioritize the decryption of traffic to high- or medium-risk  URL categories , traffic destined for critical servers, or business-critical traffic. Some traffic can't be decrypted for technical, legal, or other reasons. Understand the traffic you can and can’t decrypt when developing a decryption strategy. Use the  Decryption Best Practices Checklist  to plan, implement, and maintain your decryption deployment.

Decryption Support

Keys and Certificates for Decryption Policies

Keys are strings of numbers typically generated using a mathematical operation involving random numbers and large primes. Keys transform strings, such as passwords and shared secrets, from unencrypted plaintext to encrypted ciphertext and from encrypted ciphertext to unencrypted plaintext. Keys can be symmetric (the same key is used to encrypt and decrypt) or asymmetric (one key is used for encryption and a mathematically related key is used for decryption). Any system can generate a key.

X.509 certificates establish trust between a client and a server to establish an SSL connection. A client attempting to authenticate a server (or a server authenticating a client) knows the structure of the X.509 certificate and therefore knows how to extract identifying information about the server from fields within the certificate, such as the FQDN or IP address (called a  Common Name  or  CN  within the certificate) or the name of the organization, department, or user to which the certificate was issued. A certificate authority (CA) must issue all certificates. After the CA verifies a client or server, the CA issues the certificate and signs it with a private key.

If you have two CAs with the same subject and key, and one CA expires, delete (custom) or disable (predefined) the expired CA. If you don't delete or disable an expired CA, the Next-Generation Firewall (NGFW) can build a chain to the expired CA if it is enabled in the trusted chain resulting in a Block page.

When you apply a decryption policy rule to traffic, a session between the client and the server is established only if the NGFW trusts the CA that signed the server certificate. To establish trust, the NGFW must have the server root CA certificate in its certificate trust list (CTL) and use the public key in the root CA certificate to verify the signature. Next, the NGFW presents a copy of the server certificate signed by the Forward Trust certificate to the client for authentication.

Alternatively, you can configure the NGFW to use an enterprise CA as a Forward Trust certificate for SSL Forward Proxy. If the NGFW does not have the server root CA certificate in its CTL, it presents a Forward Untrust copy of the server certificate to the client. The Forward Untrust certificate ensures that clients receive a certificate warning when attempting to access sites hosted by a server with untrusted certificates.

You can also use certificates when  excluding servers from SSL decryption  for technical reasons, such as certificate pinning. SSL decryption requires  keys and certificates  to establish the NGFW as a trusted third party and to establish trust between a client and a server to secure an SSL/TLS connection. SSH decryption doesn't require certificates.

You can also  verify the revocation status of certificates  used for decryption.

Checking the revocation status of certificates used for SSL/TLS decryption adds time to the process of establishing the session. The first attempt to access a site might fail if the verification does not finish before the session times out. For these reasons, verification is disabled by default.

For detailed information on certificates, see  Certificate Management .

To control the trusted CAs that your NGFW trusts, use the  Default Trusted Certificate Authorities  tab on your web interface.

The following table describes the different certificates used for decryption.

Certificates Used With Decryption

Description

Forward Trust (Used for SSL Forward Proxy decryption)

The certificate the NGFW presents to clients during decryption if the site the client attempting to connect to has a certificate signed by a CA that the NGFW trusts. To configure the Forward Trust certificate presented to clients when the server certificate is signed by a trusted CA, see  Configure SSL Forward Proxy .

By default, the NGFW determines the key size to use for the client certificate based on the key size of the destination server. However, you can  configure the key size  for SSL Forward Proxy server certificates. For added security, consider storing the private key associated with the Forward Trust certificate on a hardware security module (HSM). (See  Store Private Keys on an HSM .)

Back up the private key associated with the NGFW's Forward Trust CA certificate (not the NGFW's master key) in a secure repository so that if an issue occurs with the NGFW, you can still access the Forward Trust CA certificate. For added security, consider storing the private key associated with the Forward Trust certificate on an HSM. (See  Store Private Keys on an HSM .)

Forward Untrust (Used for SSL Forward Proxy decryption)

The certificate the NGFW presents to clients during decryption if the site the client is attempting to connect to has a certificate that is signed by a CA that the NGFW does not trust. To configure a Forward Untrust certificate, see  Configure SSL Forward Proxy .

SSL Inbound Inspection

The certificates of the servers on your network for which you want to perform SSL Inbound Inspection of traffic destined for those servers. Import the server certificates onto the NGFW or management platforms for NGFW or Prisma Access.

Beginning in PAN-OS 8.0, NGFWs use the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) algorithm to perform strict certificate checking. This means that if the NGFW uses an intermediate certificate, you must reimport the certificate from your web server to the NGFW after you upgrade to a PAN-OS 8.0 or later release and combine the server certificate with the intermediate certificate (install a chained certificate). Otherwise, SSL Inbound Inspection sessions that have an intermediate certificate in the chain fail. To install a chained certificate:

  1. Open each certificate (.cer) file in a plain-text editor such as Notepad.
  2. Paste each certificate end-to-end with the Server Certificate at the top with each signer included below.
  3. Save the file as a text (.txt) or certificate (.cer) file. The name of the file cannot contain blank spaces.
  4. Import the combined (chained) certificate.

SSL Decryption and Subject Alternative Names (SANs)

Some browsers require server certificates to use a Subject Alternative Name (SAN) to specify the domains the certificate protects. These browsers no longer support certificate matching based on a server certificate's Common Name (CN). SANs enable a single server certificate to protect multiple hostnames or domains, while CNs are less well-defined than SANs and can protect only a single domain or all first-level subdomains on a domain.

If a server certificate contains only a CN, browsers that require a SAN will not allow end users to connect to the requested web resource. To address this, NGFWs can add a SAN to the impersonation certificate they generate, establishing themselves as trusted third-parties during SSL decryption. When a server certificate contains only a CN, the NGFW performing SSL decryption copies the server certificate CN to the impersonation certificate SAN. The NGFW presents the impersonation certificate with the SAN to the client, and the browser is able to support the connection. End users can continue to access the resources they need, and the NGFW can decrypt the sessions.

To enable SAN support for decrypted SSL traffic, update the decryption profile attached to the relevant decryption policy rule:

SSL Decryption for Elliptical Curve Cryptography (ECC) Certificates

The NGFW automatically decrypts SSL traffic from websites and applications using Elliptic Curve Cryptography (ECC) certificates, including Elliptic Curve Digital Signature Algorithm (ECDSA) certificates. As organizations transition to using ECC certificates to benefit from the strong keys and small certificate size, you can continue to maintain visibility into and safely enable ECC-secured application and website traffic.

Decryption for websites and applications using ECC certificates is not supported for traffic that is mirrored; encrypted traffic using ECC certificates must pass through a NGFW directly for the NGFW to decrypt it.

You can use a  hardware security module (HSM)  to store the private keys associated with ECDSA certificates.

Perfect Forward Secrecy Support for SSL Decryption

Perfect Forward Secrecy (PFS) is a secure communication protocol that prevents the compromise of one encrypted session from leading to the compromise of multiple encrypted sessions. With PFS, a server generates unique private keys for each secure session it establishes with a client. If an attacker compromises a server's private key, they can only access the single session associated with that key. An attacker cannot retrieve data from past and future sessions because the server establishes each connection with a uniquely generated key.

You can decrypt SSL sessions established with Perfect Forward Secrecy, maintaining PFS protection for past and future sessions. This includes SSL sessions with servers that present Elliptic Curve Cryptography (ECC) certificates or Subject Alternative Name (SAN) certificates. Decryption profiles support the Diffie-Hellman (DHE) and Elliptic Curve Diffie-Hellman (ECDHE) key exchange algorithms by default. To enable PFS support for decryption, apply a decryption profile with the  DHE  and  ECDHE  key exchange algorithms selected to an SSL Inbound Inspection or SSL Forward Proxy decryption policy rule.

If you use the DHE or ECDHE key exchange algorithms to enable PFS support for SSL decryption, you can use an  hardware security module (HSM)  to store the private keys for SSL Inbound Inspection.

When you configure SSL Inbound Inspection and use a PFS cipher, session resumption is not supported.

A screenshot of a computer AI-generated content may be incorrect.

Decryption Profiles

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:

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 .

no-decryption profile

 to  decryption policy rules for undecrypted traffic  to block sessions with expired certificates and untrusted issuers.

SSL Decryption

, 

No Decryption

, and 

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.

Expand all

Collapse all

Expand all

Collapse all

Expand all

Collapse all

The following table lists the profile types and the settings that they apply to.

Profile Settings and Profile Types Matrix

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 further increase security, you can require multi-factor authentication to complete the user login process.

The following sections summarize the profile settings and recommendations for SSL Forward Proxy, SSL Inbound Inspection, and the SSL Protocol Settings. Select an option to learn more about the unique settings and recommendations offered.

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 .

A screenshot of a computer AI-generated content may be incorrect.

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.

A screenshot of a computer AI-generated content may be incorrect.

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.

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.

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.

A screenshot of a computer AI-generated content may be incorrect.

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 :

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.

A screenshot of a computer AI-generated content may be incorrect.

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.

A screenshot of a computer AI-generated content may be incorrect.

SSL Forward Proxy

You can  configure SSL Forward Proxy  to decrypt and inspect SSL/TLS traffic from internal users to the internet. SSL Forward Proxy decryption prevents malware concealed as SSL encrypted traffic from being introduced into your corporate network. When you enable SSL Forward Proxy, an NGFW acts as a  forward proxy . It creates two separate sessions: one between the client and the NGFW, and the other between the NGFW and the server. The NGFW uses  certificates  to transparently represent the client to the server and the server to the client, establishing itself as a trusted third party or meddler in the middle. As a result, the client believes it's communicating directly with the server, and the server believes it's communicating directly with the client. All web traffic goes through the NGFW, which applies decryption profiles and Security policy rules and profiles to the traffic.

(For details on certificates, see  Keys and Certificates for Decryption Policies .)

Because the NGFW is a proxy device, it can’t decrypt certain sessions, such as those with client authentication or pinned certificates. It also doesn't support high availability (HA) sync for decrypted SSL sessions.

The following figure shows this process in detail.

A diagram of a computer server AI-generated content may be incorrect.

  1. The internal client on your network attempts to initiate a TLS session with an external server.
  2. The NGFW intercepts the client’s SSL certificate request. For the client, the NGFW acts as the external server, though the actual secure session is established with the NGFW.
  3. The NGFW forwards the client’s SSL certificate request to the server to initiate a separate session with the server. To the server, the NGFW looks like the client, the server doesn’t know there’s a meddler in the middle, and the server verifies the certificate.
  4. The server sends the NGFW a signed certificate intended for the client.
  5. The NGFW analyzes the server certificate. If the server certificate is signed by a CA that the NGFW trusts and meets the policy rules and profiles you configure, the NGFW generates an SSL Forward Trust copy of the server certificate and sends it to the client.

If the server certificate is signed by a CA that the NGFW does not trust, the NGFW generates an SSL Forward Untrust copy of the server certificate and sends it to the client. The certificate copy contains extensions from the original server certificate and is called an  impersonation  certificate because it is not the actual server certificate. If the NGFW does not trust the server, the client displays a warning message that the site they’re attempting to connect to isn’t trusted.  Enable users to opt out of SSL decryption , so that the client can choose to proceed or terminate the session.

  1. The client verifies the NGFW’s impersonation certificate. The client then initiates a session key exchange with the server, which the NGFW proxies in the same manner as it proxies the certificates. The NGFW forwards the client key to the server and makes an impersonation copy of the server key for the client, so that the NGFW remains an “invisible” proxy and the client and server believe their session is with each other. Now, all parties have the certificates and keys required and the NGFW can decrypt the traffic.
  2. All SSL session traffic flows through the NGFW transparently between the client and the server. The NGFW decrypts the SSL traffic, applies Security policy rules and security profiles and decryption profiles to the traffic, reencrypts the traffic, and then forwards it.

When you configure SSL Forward Proxy, the proxied traffic does not support DSCP code points or QoS.

 

SSL Inbound Inspection

Configure SSL Inbound Inspection  to decrypt and inspect inbound SSL/TLS traffic from clients to targeted network servers and block suspicious sessions. For example, suppose a malicious actor wants to exploit a known vulnerability with your web server. Inbound SSL/TLS decryption provides visibility into the traffic, enabling the Next-Generation Firewall (NGFW) to respond to the threat proactively.

SSL Inbound Inspection works similarly to  SSL Forward Proxy , except the direction of traffic it focuses on differs. The NGFW acts as a meddler in the middle between an external client and an internal server. The NGFW creates two separate and secure sessions: one between the client and itself, and another between itself and the server. It also generates a new session key for each secure session. SSL Inbound Inspection also supports SSL session resumption because the NGFW functions as a proxy device.

The NGFW can't decrypt some sessions, such as sessions with client authentication or pinned certificates, because it is a proxy device. It also doesn't support high availability (HA) sync for decrypted SSL sessions.

SSL Inbound Inspection requires  installation of the certificate  and private key of each internal server you want to protect onto the NGFW or management platforms for NGFW and Prisma Access. The NGFW validates that the certificate sent by the targeted server during the SSL/TLS handshake matches a certificate in your decryption policy rule. If there is a match, the NGFW forwards the server certificate to the client requesting server access and establishes a secure connection.

The TLS versions that your web server supports determine how you should install the server certificate and key. If your web server supports TLSv1.2 and Rivest, Shamir, Adleman (RSA) or  Perfect Forward Secrecy (PFS)  key exchange algorithms  and  your end-entity (leaf) certificate is signed by intermediate certificates, we recommend  uploading a certificate chain  (a single file). Uploading the chain avoids client-side server certificate authentication issues.

TLSv1.3 removes support for the RSA key exchange algorithm.

TLSv1.3 connections are handled differently than TLSv1.2 connections. During TLSv1.3 handshakes, the NGFW sends the client the same certificate or certificate chain that it receives from the server. As a result, uploading the server certificate and private key to the NGFW is sufficient if you correctly set up your web server. For example, if your server’s leaf certificate is signed by intermediate certificates, install the chain of certificates on the server to avoid client-side server authentication issues.

Multiple Certificate Support

Create separate  decryption profiles  for servers with different security capabilities. Configure the  SSL Protocol Settings  for the highest level of security that a server supports, but consider performance to ensure that the NGFW and Prisma Access resources can handle the higher processing load that higher security protocols and algorithms require. For example, if a set of servers supports only RSA, configure a decryption profile that exclusively supports RSA. If a server supports both RSA and PFS, select RSA and PFS key exchange algorithms.

When you configure SSL Inbound Inspection, the proxied traffic does not support DSCP code points or QoS.

SSH Proxy

In an SSH Proxy configuration, a Next-Generation Firewall (NGFW) sits between a client and a server.  Configuring SSH Proxy  enables an NGFW to decrypt inbound and outbound SSH connections, preventing attackers from using the SSH protocol to tunnel unwanted applications and content. SSH decryption does not require certificates. The NGFW automatically generates the key used for SSH connections when it boots up. During the boot-up process, the NGFW checks for an existing key. If there isn't one, the NGFW generates a key. The NGFW uses the key to decrypt SSH sessions for all virtual systems configured on it and all SSH v2 sessions.

SSH allows tunneling (or port forwarding), which is the transmission of data from a client to a server over an encrypted connection. Bad actors can use SSH tunneling to hide malicious traffic from decryption. The NGFW can't decrypt traffic inside an SSH tunnel. Instead, it identifies the presence of an SSH tunnel using  App-ID  and blocks all traffic in the tunnel. SSH tunneling sessions can tunnel X11 Windows packets and TCP packets. A single SSH connection can contain multiple channels. When you apply a decryption profile for SSH Proxy to a Security policy rule that allows SSH traffic, the NGFW determines the App-ID of the traffic in each channel to identify the channel type. The channel type can be:

When the channel type is session, the NGFW identifies the traffic as allowed SSH traffic such as SFTP or SCP. When the channel type is X11, forwarded-tcpip, or direct-tcpip, the NGFW identifies the traffic as SSH tunneling traffic and blocks it.

To block all SSH tunnel traffic, configure a Security policy rule for the  ssh-tunnel  application with the  Action  set to  Deny  (along with a Security policy rule that allows traffic from the  ssh  application).

To reduce your attack surface, limit SSH use to administrators who need to manage network devices, log all SSH traffic, and consider enabling  Multi-Factor Authentication  to ensure that only legitimate users can use SSH to access devices.

When SSH decryption is enabled, authenticating to hosts with a certificate fails. This happens because the SSH client can no longer use public key authentication, preventing the server from completing the TLS handshake using a public key that the client decrypts with its private key. Use username and password authentication to initiate an SSH session instead.

For systems that must use key-based authentication, configure your SSH decryption policy rule to exclude systems that require public key authentication. To edit the decryption policy rule:

  1. Go to  PoliciesDecryption , and select the policy rule that controls SSH decryption.
  2. Select the  Destination  tab.
  3. Add the IP addresses of the systems you want to exclude from the rule.
  4. Select  Negate .
  5. Click  OK .
  6. Commit  your changes.

The following figure shows how SSH Proxy decryption works.

A screenshot of a computer AI-generated content may be incorrect.

  1. The client sends an SSH request to the server to initiate a session.
  2. The NGFW intercepts the client’s SSH request.
  3. The NGFW forwards the request to the server and initiates an SSH session with the server. This establishes the first of two separate sessions that the NGFW creates. Each session establishes a separate SSH tunnel.
  4. The server responds to the request, which the NGFW intercepts.
  5. The NGFW inserts the SSH key into the server’s response and forwards it to the client. This establishes the second separate session (and separate SSH tunnel) that the NGFW creates.
  6. (First part of “7” in the diagram) After the NGFW establishes separate sessions with the server and the client, the NGFW acts as a proxy between them.
  7. The NGFW checks the traffic between the client and server to see if it's routed normally or if it uses SSH port forwarding (SSH tunneling). If the NGFW identifies SSH port forwarding, the NGFW blocks the tunneled traffic and restricts it according to the configured Security policy rule. The NGFW only looks for SSH port forwarding, it does not perform content and threat inspection on SSH tunnels.

When you configure SSH Proxy, the proxied traffic does not support DSCP code points or QoS.

TLS 1.3 Decryption

TLSv1.3 is the latest version of the TLS protocol, improving application security and performance. Next-Generation Firewalls (NGFW and Prisma Access support TLSv1.3 for  SSL Forward Proxy  and  SSL Inbound Inspection  decryption, decrypted  Network Packet Broker  traffic, and  Decryption Port Mirroring . This support enables you to decrypt, gain full visibility into, and prevent known and unknown threats in TLSv1.3 traffic.

To support TLSv1.3 decryption, apply a decryption profile with TLSv1.3 configured as the minimum or maximum protocol version to existing and new decryption policy rules. You can edit existing decryption profiles to support TLSv1.3. If you don’t enable TLSv1.3, PAN-OS defaults to TLSv1.2 as the maximum protocol version. If a website or application doesn't support TLSv1.3, the Next-Generation Firewall (NGFW) automatically selects a TLS protocol version that the server supports.

To establish a TLSv1.3 connection, both client and server must support negotiation with TLSv1.3 ciphers. The following decryption algorithms are supported for TLSv1.3 connections:

If the  Max Version  a decryption profile supports is  Max , then the profile supports TLSv1.3 and automatically uses TLSv1.3 with sites supporting this protocol. The  Max  option ensures that the traffic that the profile controls uses the strongest available protocol version. It also future-proofs the decryption profile as it provides automatic support for new TLS versions as they are released.

You can configure  TLSv1.3  as the  Max Version  instead of  Max . However, when the next TLS version releases, you'll need to update the decryption profile.

Min Version  specifies the weakest version of the protocol that the traffic can use. Setting the minimum protocol version to  TLSv1.3  achieves the tightest security because it requires traffic to use TLSv1.3 or greater protocol versions. This blocks weaker protocols and makes weaker key exchange, encryption, and authentication algorithms unavailable. Further, TLSv1.3 requires the use of  Perfect Forward Secrecy (PFS) . Apply a profile that sets TLSv1.3 as the minimum version only to application traffic that only supports TLSv1.3.If

As not all applications support TLSv1.3, follow  decryption best practices  and set the  Min Version  of the TLS protocol to  TLSv1.2  and the  Max Version  to  Max . If access to websites or applications with weaker TLS protocols is a business requirement, create separate decryption profiles with a  Min Version  that allows the weaker protocol and attach it to a decryption policy rule that specifies the traffic you need to allow with the weaker TLS protocol.

For decryption policy rules that support mobile applications, many of which use pinned certificates, set the  Max Version  to  TLSv1.2 . TLSv1.3 encrypts certificate information that was not encrypted in previous TLS versions, preventing NGFWs from automatically adding decryption exclusions based on certificate information. As a result, if you enable TLSv1.3, the NGFW may drop some mobile application traffic. To mitigate potential issues, create a No Decryption policy rule for this traffic. If you know the specific mobile applications required for business, consider creating a separate decryption policy rule and decryption profile for those applications. This approach allows you to enable TLSv1.3 for all other traffic.

Avoid attaching  No-decryption profiles  to  decryption policy rules  that exclusively handle TLSv1.3 traffic. TLSv1.3 encrypts certificate information, so the NGFW doesn't have visibility into this information and therefore can’t block sessions with expired certificates or untrusted issuers, making the profile ineffective. (The NGFW can perform certificate checks with TLSv1.2 and earlier protocols because those protocols don’t encrypt certificate information. You should apply No Decryption profiles to decryption policy rules handling TLSv1.2 and earlier traffic.) However, you can log undecrypted traffic of all types by selecting the options to log successful and unsuccessful TLS handshakes in decryption policy rules. Unsuccessful TLS handshakes are logged by default.

If you allow unsupported modes in the  SSL Protocol Settings  of a decryption profile, the NGFW and Prisma Access automatically adds this traffic to its  Local SSL Decryption Exclusion Cache .The NGFW and Prisma Access still decrypts and inspects traffic that is downgraded from TLSv1.3 to TLSv1.2. The  Reason  shown in the cache for the added servers is  TLS13_UNSUPPORTED .

If you downgrade from PAN-OS 11.1 to a previous version, any decryption profile that specifies TLSv1.3 as the  Min Version  or the  Max Version  changes to the highest supported version. For example, downgrading from PAN-OS 11.1 to PAN-OS 9.1 replaces TLSv1.3 with TLSv1.2. If a Panorama device on PAN-OS 11.1 pushes the configuration to devices that run older versions of PAN-OS, any decryption profile that specifies TLSv1.3 as the  Min Version  or the  Max Version  also changes to the highest supported version.