Introduction to Decryption

The Transport Layer Security (TLS) protocol (evolved from Secure Sockets Layer (SSL) ) and the Secure Shell (SSH) protocol are fundamental for securing network communications. SSL/TLS typically secures web traffic (HTTPS), while SSH secures remote access. Both rely on public/private key cryptography to encrypt data, rendering it unreadable to unauthorized parties.

However, this encryption can be exploited by attackers to hide malicious activities. For instance, malware delivered via an HTTPS site can infect users and spread laterally within a network, undetected by security tools that don't inspect encrypted traffic. Therefore, encrypted traffic should not be implicitly trusted.

Decryption is the process of converting this encrypted data back to its original, readable format. This allows Palo Alto Networks Next-Generation Firewalls (NGFWs) and Prisma Access to inspect the content for threats, enforce policies, and ensure compliance.

Why Decrypt Traffic?

Decrypting SSL/TLS and SSH traffic enables security platforms to:

• Prevent malicious payloads hidden within encrypted traffic from entering the network.
• Prevent sensitive data exfiltration hidden within encrypted outbound connections.
• Ensure only sanctioned applications are running over secure channels (App-ID visibility).
• Identify and enforce compliance with legal, corporate, and regulatory policies.

SSL/TLS Decryption Fundamentals

SSL/TLS decryption positions the NGFW as a trusted intermediary (often called a "man-in-the-middle" or proxy) between the client and the server. This involves establishing two separate secure sessions:

1. Client <===> NGFW
2. NGFW <===> Server

The NGFW uses certificates and keys to manage these sessions transparently. The client believes it's directly connected to the server, and the server believes it's directly connected to the client. This allows the NGFW to decrypt the traffic, apply security inspection (Threat Prevention, URL Filtering, etc.), and then re-encrypt it before forwarding it to the destination.

There are two primary modes for SSL/TLS decryption:

• SSL Forward Proxy: Decrypts traffic initiated by internal users going out to external websites/servers (outbound traffic).
• SSL Inbound Inspection: Decrypts traffic initiated by external users coming into internal servers (inbound traffic).

Decryption relies heavily on certificate management and trust relationships.

SSH Decryption (SSH Proxy)

SSH Proxy allows the NGFW to decrypt and inspect SSH traffic. Unlike SSL/TLS, SSH decryption doesn't typically rely on certificates presented to the client/server. Instead, the NGFW uses an internally generated key pair to proxy the connection.

The primary goal of SSH Proxy is to prevent malicious use of SSH tunneling (port forwarding), where attackers might hide forbidden applications or exfiltrate data within an allowed SSH connection. The NGFW uses App-ID to identify the type of channel within the SSH session:

• session: Normal interactive or file transfer (SFTP/SCP) traffic, usually allowed.
• X11, forwarded-tcpip, direct-tcpip: Indicate tunneling, which is typically blocked by policy.

You configure SSH Proxy via Decryption Policy rules, often blocking the ssh-tunnel application while allowing the base ssh application.

Decryption Types Detailed

SSL Forward Proxy

This mode is used to decrypt and inspect outbound traffic initiated by internal users connecting to external websites/services. The NGFW acts as a proxy, intercepting the client's connection attempt and establishing separate secure sessions with both the client and the destination server.

Process Flow:

1. Client initiates TLS connection to external server.
2. NGFW intercepts the request.
3. NGFW initiates its own TLS connection to the external server (acting as the client).
4. Server sends its certificate to the NGFW.
5. NGFW validates the server certificate against its trusted CA list.
   • If trusted: NGFW generates an impersonation certificate using the Forward Trust CA and sends it to the client.
   • If untrusted: NGFW generates an impersonation certificate using the Forward Untrust CA and sends it to the client (triggering a browser warning).
6. Client validates the impersonation certificate (it must trust the Forward Trust CA).
7. NGFW proxies the key exchange between client and server, gaining access to the session keys.
8. NGFW decrypts traffic, inspects it according to policy, re-encrypts, and forwards.

SSL Inbound Inspection

This mode decrypts and inspects inbound traffic destined for internal servers (e.g., company web servers) initiated by external clients. It allows the NGFW to detect threats targeting internal resources.

Requirements:

• The internal server's actual certificate (including its private key) must be imported onto the NGFW.

Process Flow:

1. External client initiates TLS connection to internal server's public IP.
2. NGFW intercepts the connection (often via NAT).
3. NGFW uses the imported server certificate/key to establish the TLS session with the client (acting as the server).
4. NGFW establishes a separate (often unencrypted, but can be TLS) session to the actual internal server.
5. NGFW decrypts client traffic, inspects according to policy, potentially re-encrypts (if backend connection is TLS), and forwards to the internal server. Replies are processed in reverse.

If the server certificate involves intermediate CAs, the full chain should usually be uploaded to the NGFW to avoid client validation issues, especially pre-TLSv1.3.

SSH Proxy

Used to decrypt and control SSH sessions, primarily to prevent SSH tunneling.

Process Flow:

1. Client initiates SSH connection to server.
2. NGFW intercepts the request.
3. NGFW initiates its own SSH session to the server (acting as client).
4. Server responds; NGFW intercepts.
5. NGFW uses its internally generated SSH key pair to establish an SSH session with the original client (acting as server).
6. NGFW proxies traffic between the two established SSH sessions.
7. NGFW uses App-ID to inspect the channel type within the SSH connection. If tunneling (X11, forwarded-tcpip, direct-tcpip) is detected, it blocks the tunneled traffic based on policy. Regular SSH session traffic (SFTP, SCP, shell) is allowed if permitted by policy.

TLS 1.3 Decryption

TLS 1.3 enhances security and performance over previous versions. Palo Alto Networks platforms support TLS 1.3 decryption for SSL Forward Proxy, SSL Inbound Inspection, Network Packet Broker, and Decryption Port Mirroring.

Key Differences/Considerations for TLS 1.3:

• Uses different, more secure cipher suites (e.g., AES-GCM, CHACHA20-POLY1305).
• Mandates Perfect Forward Secrecy (PFS) using ECDHE key exchange (RSA key exchange is not supported).
• Encrypts parts of the handshake, including the server certificate, which were previously sent in cleartext.
• **Impact on Exclusions:** Because the certificate is encrypted early in the handshake, the NGFW cannot automatically exclude sessions based on certificate attributes (like CN or pinned certificates) as easily as with TLS 1.2. Manual exclusions or policy-based exclusions might be needed more often, especially for mobile apps.
• **Impact on No-Decryption Profiles:** Certificate checks within "No Decryption" profiles (block expired/untrusted) are ineffective for TLS 1.3 traffic because the firewall cannot see the certificate details without decrypting.

Configuration:

• Configure the minimum and maximum supported TLS versions in the Decryption Profile's SSL Protocol Settings.
• Setting Max Version to Max is recommended for future-proofing.
• Setting Min Version to TLSv1.3 offers the highest security but may break applications not supporting it. TLSv1.2 is often the recommended minimum for broader compatibility.
• For environments with mobile apps potentially using pinned certificates, setting Max Version to TLSv1.2 might be necessary unless specific exclusions are configured.

Keys and Certificates for Decryption

SSL/TLS decryption requires careful management of digital certificates and cryptographic keys.

• Keys: Numerical strings used for encryption and decryption (symmetric or asymmetric).
• X.509 Certificates: Digital documents binding an identity (like a server's domain name) to a public key, signed by a trusted Certificate Authority (CA). They establish trust.
• Certificate Authority (CA): An entity trusted by clients and servers to issue and vouch for certificates.
• Certificate Trust List (CTL): The list of CAs that the NGFW trusts.
• Common Name (CN) & Subject Alternative Name (SAN): Fields within a certificate identifying the domain(s) it protects. Modern browsers primarily rely on SANs.

Certificate Types in Palo Alto Networks Decryption:

Key Considerations:

• The NGFW must trust the CA that signed the original server's certificate to generate a Forward Trust impersonation certificate.
• Client devices must be configured to trust the NGFW's Forward Trust CA certificate to avoid browser warnings for trusted sites during SSL Forward Proxy.
• For SSL Inbound Inspection, the server's certificate and private key must be securely imported onto the NGFW.
• Consider using a Hardware Security Module (HSM) for enhanced protection of private keys used for decryption.
• Configure certificate revocation checking (OCSP/CRL) in Decryption Profiles for added security, understanding potential performance impacts.
• Enable the "Append certificate’s CN value to SAN extension" option in Decryption Profiles to handle older server certificates lacking SANs compatibility with modern browsers.

Decryption Profiles

Decryption Profiles are attached to Decryption Policy rules and define *how* the firewall handles specific aspects of the SSL/TLS or SSH session, especially regarding security checks and protocol parameters. They allow granular control over decrypted traffic.

Key Functions Controlled by Decryption Profiles:

• Protocol Validation: Block sessions using unsupported or weak SSL/TLS/SSH protocol versions.
• Algorithm/Cipher Validation: Block sessions using weak key exchange, encryption, or authentication algorithms.
• Certificate Verification (SSL/TLS): Block sessions based on certificate issues:
  • Expired certificates
  • Untrusted issuers (CAs not in the NGFW's trust list)
  • Unknown certificate revocation status (if OCSP/CRL checks are enabled and fail)
  • Certificate status check timeouts
  • Mismatched Server Name Indication (SNI) vs. certificate SAN/CN
  • Restrict specific certificate extensions
• Unsupported Mode Checks: Block sessions requiring client authentication (for SSL Forward Proxy) or using unsupported cipher suites.
• Failure Checks: Block sessions if decryption resources are unavailable or if an HSM required for key operations is down.

Types of Decryption Profiles:

• SSL Forward Proxy Profile: Controls outbound SSL/TLS decryption settings. Includes server certificate verification options.
• SSL Inbound Inspection Profile: Controls inbound SSL/TLS decryption settings. Does not include server certificate verification options (as the server cert is explicitly configured in the policy).
• SSH Proxy Profile: Controls SSH decryption settings, primarily focusing on blocking unsupported algorithms and handling SSH errors.
• No Decryption Profile: Applied to traffic explicitly excluded from decryption by policy (e.g., for privacy reasons like financial or healthcare sites). Allows basic certificate checks (blocking expired/untrusted issuers for TLSv1.2 and earlier) without performing full decryption.

Decryption Profile Best Practices:

• Create strict baseline profiles (e.g., requiring TLS 1.2/1.3, strong ciphers).
• Create separate, more lenient profiles *only* for specific legacy sites/apps that require weaker protocols/ciphers, and apply these profiles via targeted Decryption Policy rules. Do not weaken the main profile.
• Use the "Block" options for unsupported modes and certificate issues unless there's a strong business justification to only allow with warnings.
• Apply "No Decryption" profiles with checks enabled for traffic excluded for policy reasons (privacy, legal).
• Do *not* use "No Decryption" policy rules for traffic excluded for technical reasons (e.g., pinned certs); use the global Decryption Exclusion list instead (Device > Setup > Session > Decryption Settings).

Profile Settings vs. Profile Types Matrix:

Automatic Decryption Bypasses & Exclusions

While Decryption Policies and Profiles define the *intended* scope of decryption, certain technical characteristics encountered during the SSL/TLS handshake can force the firewall to automatically bypass decryption for specific sessions, even if a "decrypt" action is configured in the matching policy rule. This typically happens when the firewall, acting as a proxy, cannot fulfill specific security requirements of the client or server application.

Common Scenarios for Automatic Bypass:

• Client Authentication Required:

  If the destination server requests a certificate from the client for mutual authentication (mTLS), the firewall (acting as the server towards the client during SSL Forward Proxy) cannot provide or correctly proxy this client certificate. Similarly, in SSL Inbound Inspection, the firewall cannot demand a client certificate if the actual backend server doesn't require one. When client authentication is detected as mandatory by the server, the firewall typically bypasses decryption for that session to allow the direct client-server authentication to proceed (or fail based on the client/server capabilities).

• Certificate Pinning:

  Some applications (especially mobile apps) implement certificate pinning. This means the application is hard-coded to only trust the specific public key or certificate of the legitimate destination server. When the firewall performs SSL Forward Proxy and presents its impersonation certificate (signed by the Forward Trust CA), the application detects that this is not the expected certificate/key and terminates the connection. To avoid breaking these applications, the firewall often needs to bypass decryption for pinned sessions. While the *detection* might lead to a manual exclusion being added later, the initial sessions might fail until bypassed or excluded.

• Unsupported Cipher Suites / Protocol Versions (Leading to Exclusion Cache):

  If a Decryption Profile is configured to block sessions using unsupported cipher suites or protocol versions, the session is simply blocked. However, if the profile is configured to *allow* these but the firewall *technically cannot* handle the specific mode for decryption/proxying, the decryption attempt might fail. When certain failures occur repeatedly (like unsupported modes if not explicitly blocked), the firewall can automatically add the server to the Local SSL Decryption Exclusion Cache (viewable via CLI: show system setting ssl-decrypt exclude-cache ). This prevents the firewall from repeatedly attempting and failing to decrypt sessions to that server, effectively bypassing decryption for subsequent connections to that cached server entry.

Handling and Visibility:

• Sessions automatically bypassed due to these technical reasons are typically allowed to pass through the firewall *without* decryption (assuming a Security Policy rule allows the underlying traffic).
• The reason for the bypass might be logged in the Traffic logs or sometimes inferred from Decryption log errors if the attempt failed before the bypass occurred.
• Servers added to the Local SSL Decryption Exclusion Cache are bypassed automatically for a period, reducing resource consumption from failed decryption attempts.

Decryption Broker

The Decryption Broker feature allows the Palo Alto Networks NGFW or Prisma Access to forward a copy of decrypted traffic to a series of third-party security services (like specialized Intrusion Prevention Systems (IPS), Data Loss Prevention (DLP) tools, or custom sandboxes) for additional inspection. This enables organizations to leverage existing security investments or specialized tools that require cleartext visibility.

Unlike Decryption Mirror which simply sends a one-way copy, Decryption Broker typically sends traffic *through* a security chain and expects the traffic to be returned to the firewall for final forwarding to its original destination.

Key Characteristics:

• Purpose: Integrate external security tools requiring cleartext traffic inspection into the security workflow.
• Traffic Flow: Supports bi-directional inspection where traffic goes out to the security chain and returns to the firewall before being re-encrypted and sent to the destination.
• Dedicated Interfaces: Requires dedicated physical or Aggregate Ethernet interfaces configured for the Decryption Broker function.
• Licensing: Requires a specific Decryption Broker license .

Deployment Modes (Security Chains):

• Layer 3 Security Chain
• Transparent Bridge Security Chain

Decryption Broker vs. Decryption Mirror:

• Mirror: Sends a one-way *copy* of decrypted traffic. Uses a "Decryption Mirror" interface type. Requires Decryption Port Mirror license.
• Broker: Forwards decrypted traffic *through* an external security chain. Uses standard interface types configured within the Broker settings. Requires Decryption Broker license.

Decryption Support Summary

• Perfect Forward Secrecy (PFS): Supported via DHE and ECDHE key exchange algorithms (enabled by default in Decryption Profiles).
• Hardware Security Module (HSM): Supported for securely storing private keys used in SSL Forward Proxy and SSL Inbound Inspection.
• SSL Session Resumption: Supported for SSL Forward Proxy and SSL Inbound Inspection because the NGFW acts as a proxy.
• High Availability (HA): Decrypted sessions are *not* synchronized between HA peers. New sessions after failover are decrypted based on policy.
• Elliptical Curve Cryptography (ECC): Supported for decryption (including ECDSA certificates).
• Decryption Port Mirroring: Allows sending a cleartext copy of decrypted traffic to a third-party tool via a dedicated interface type (requires license). Be mindful of privacy regulations.
• Decryption Broker: Allows forwarding decrypted traffic through an inline chain of third-party tools (requires license).