Palo Alto Networks Decryption Concepts

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.

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:

Certificate Type	Description & Use Case
Forward Trust Certificate	A CA certificate (can be self-signed or issued by an internal enterprise PKI) configured on the NGFW. Used in SSL Forward Proxy to re-sign server certificates from websites that the NGFW *trusts*. The client's browser must trust this Forward Trust CA.
Forward Untrust Certificate	A certificate (typically self-signed) configured on the NGFW. Used in SSL Forward Proxy to re-sign server certificates from websites that the NGFW *does not* trust (e.g., expired, self-signed, unknown CA). This intentionally presents a warning to the end-user's browser.
SSL Inbound Inspection Certificate(s)	The actual server certificate(s) (including the private key) for your internal servers that you want to protect. These are imported onto the NGFW and used in SSL Inbound Inspection policies. If intermediate CAs are involved, the full chain should often be imported.
Server Certificate (General)	The certificate presented by any web server during a TLS handshake. The NGFW validates this against its trusted CA list.
Root CA / Intermediate CA	Certificates that form the chain of trust. The Root CA is implicitly trusted. Intermediate CAs are signed by the Root or another Intermediate, eventually signing the end-entity (server) certificate.

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:

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

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.
• Mechanism: After decrypting traffic (SSL Forward Proxy or SSL Inbound Inspection), the firewall forwards the cleartext traffic out specific, dedicated interfaces towards the external security tool chain.
• 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. Virtual interfaces cannot be used for Broker forwarding.
• Licensing: Requires a specific Decryption Broker license (separate from the Decryption Mirror license).

Deployment Modes (Security Chains):

Decryption Broker supports two main ways to integrate the external tools:

• Layer 3 Security Chain:
  • The firewall routes the decrypted traffic to the first tool in the chain (as the next hop).
  • Each tool in the chain inspects the traffic and routes it to the next tool, eventually returning it to the firewall.
  • Requires IP addressing and routing configuration on the firewall's broker interfaces and the external tools.
  • Supports bi-directional traffic flow through the chain.
• Transparent Bridge Security Chain:
  • External tools are inserted inline between pairs of firewall interfaces configured for the broker.
  • The firewall sends traffic out one interface of a pair, the tool inspects it, and forwards it back to the firewall via the second interface in the pair.
  • Does not require IP addressing on the broker interfaces themselves (acts like a "bump in the wire" for the decrypted traffic).
  • Supports bi-directional traffic flow through the chain.

Configuration Overview:

1. Install the required Decryption Broker license.
2. Configure dedicated physical or AE interfaces for the security chain (assigning IPs for Layer 3, or pairing them for Transparent Bridge). Assign these interfaces to appropriate Security Zones.
3. Navigate to Device > Decryption Broker to define the security chain(s), specifying the interfaces and mode (Layer 3 or Transparent Bridge).
4. Configure a Decryption Policy rule (SSL Forward Proxy or SSL Inbound Inspection) to decrypt the desired traffic.
5. Within the Decryption Policy rule, enable Decryption Broker and select the configured security chain to forward the decrypted traffic.
6. Ensure Security Policies allow the traffic flow between the broker interface zones and the zones involved in the original session, as well as traffic returning from the chain.
7. Commit the configuration.

Use Cases:

• Sending decrypted traffic to specialized DLP systems for granular data leakage inspection.
• Forwarding decrypted files to third-party sandboxes or analysis tools.
• Integrating with Network Detection and Response (NDR) tools that require cleartext feeds.
• Meeting specific compliance requirements that mandate inspection by particular external tools.

Decryption Broker vs. Decryption Mirror:

• Mirror: Sends a one-way *copy* of decrypted traffic out an interface. Does not expect return traffic. Uses a "Decryption Mirror" interface type. Requires Decryption Port Mirror license.
• Broker: Forwards decrypted traffic *through* an external security chain, typically expecting the traffic to return. Uses standard interface types (Layer 3, AE) 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.