Palo Alto Networks Decryption: Unveiling Hidden Threats

In today's sophisticated threat landscape, encryption is ubiquitously used to protect data in transit. While beneficial for privacy, encryption also provides a veil for cybercriminals to hide malware, command-and-control (C2) communications, and data exfiltration. Palo Alto Networks Next-Generation Firewalls (NGFWs) provide robust decryption capabilities, allowing organizations to regain visibility into encrypted traffic and apply the full suite of security services, including App-ID, Threat Prevention (IPS, Antivirus, Anti-Spyware), URL Filtering, WildFire, and Data Loss Prevention (DLP).

Why Decrypt Traffic with Palo Alto Networks?

• Threat Prevention: Identify and block malware, viruses, spyware, and other exploits concealed in encrypted sessions. This is crucial as many modern attacks leverage encrypted channels.
• Application Visibility and Control (App-ID): Accurately identify and control applications, even those using non-standard ports or attempting to evade detection through encryption. Decryption allows App-ID to inspect the payload for precise application identification.
• URL Filtering: Enforce web access policies by inspecting the actual content of HTTPS websites, not just the Server Name Indication (SNI) in the TLS handshake. This prevents access to malicious or unauthorized sites.
• WildFire Malware Analysis: Submit suspicious files found within encrypted traffic to WildFire for dynamic analysis, identifying known and unknown malware.
• Data Loss Prevention (DLP): Prevent sensitive data exfiltration by inspecting the content of outbound encrypted communications. This requires Palo Alto Networks DLP licensing.
• Compliance: Meet regulatory requirements that mandate inspection of network traffic for security and data protection purposes.

Palo Alto Networks Decryption Modes:

Palo Alto Networks firewalls support several decryption modes to address different use cases:

1. SSL Forward Proxy: Decrypts outbound SSL/TLS traffic initiated by internal clients to external web servers.
2. SSL Inbound Inspection: Decrypts inbound SSL/TLS traffic destined for internal servers (e.g., web servers, application servers) hosted within the organization's network.
3. SSH Proxy: Decrypts and inspects SSH (Secure Shell) traffic, primarily to control and monitor SSH sessions and prevent unauthorized port forwarding (tunneling).
4. SSL Decryption Mirror (Passive Decryption): While not an active inspection mode, this feature allows the firewall to forward a copy of decrypted traffic to a third-party appliance (e.g., an external DLP or threat analytics system) for out-of-band inspection. This requires that the firewall has access to the session keys, typically through SSL Inbound Inspection or by importing session keys from servers (if supported by the server infrastructure).

General Decryption Process on PAN-OS:

Regardless of the specific mode, the decryption process on a Palo Alto Networks firewall generally involves these stages within the Single-Pass Parallel Processing (SP3) architecture:

1. Policy Match: Traffic must first match a Decryption Policy rule that specifies the action to decrypt.
2. Session Setup & Certificate Handling:
   • SSL Forward Proxy: The firewall intercepts the client's TLS handshake, impersonates the destination server to the client (using a forged certificate signed by a Forward Trust CA), and establishes a separate TLS session with the actual external server.
   • SSL Inbound Inspection: The firewall uses the imported private key and certificate of the internal server to decrypt the client's incoming TLS session, inspects the traffic, and then re-encrypts it (or establishes a new TLS session) to the internal server.
   • SSH Proxy: The firewall acts as a man-in-the-middle for the SSH connection.
3. Decryption & Inspection: The decrypted cleartext payload is then passed to other security engines like App-ID, Content-ID (Threat Prevention, URL Filtering, WildFire), and DLP for full inspection.
4. Re-encryption & Forwarding: After inspection, the traffic is re-encrypted and forwarded to its destination.

High-level overview of the decryption and inspection flow within a Palo Alto Networks firewall. Traffic matching a decryption policy undergoes decryption, full security inspection, and then re-encryption.

This overview sets the stage for a deeper exploration of each specific decryption method, their configurations, and best practices within the Palo Alto Networks ecosystem.

SSL Forward Proxy (Outbound SSL/TLS Decryption)

Use Case: SSL Forward Proxy is used to decrypt and inspect SSL/TLS traffic initiated by internal users (clients) connecting to external websites and services (servers). This is crucial for preventing malware downloads, blocking access to malicious or inappropriate websites, identifying command-and-control (C2) traffic, and preventing data exfiltration over encrypted channels.

How SSL Forward Proxy Works in PAN-OS:

The Palo Alto Networks firewall acts as a "man-in-the-middle" (MITM) for outbound SSL/TLS connections. The process involves:

1. Client Initiates Connection: An internal client attempts to establish an SSL/TLS session with an external server (e.g., https://www.example.com).
2. Firewall Interception: The firewall, based on a matching Decryption Policy rule, intercepts the client's TLS Client Hello message.
3. Firewall-Server Session: The firewall forwards the Client Hello (or a modified version) to the actual external server and establishes a legitimate SSL/TLS session with it. The server responds with its server certificate.
4. Certificate Forgery: The firewall receives the external server's certificate. It then dynamically generates (forges) a new certificate that appears to be for the requested external server (e.g., www.example.com). This forged certificate is signed by a Certificate Authority (CA) that the firewall itself controls. This CA is known as the Forward Trust Certificate .
5. Client Trust: For the client to trust this forged certificate without warnings, the client's browser/system must trust the firewall's Forward Trust CA certificate. This typically involves deploying the Forward Trust CA certificate to all internal client devices via Group Policy (GPO), MDM, or manual installation.
6. Firewall-Client Session: The firewall presents this forged certificate to the internal client. If the client trusts the Forward Trust CA, it establishes an SSL/TLS session with the firewall.
7. Decryption and Inspection: Now, the firewall has two separate SSL/TLS sessions: one with the client and one with the server. It decrypts traffic from the client, inspects it using App-ID, Content-ID (Threat Prevention, URL Filtering, WildFire, DLP), and then re-encrypts it before sending it to the external server. The same process occurs for traffic from the server to the client.

Detailed sequence of SSL Forward Proxy. The firewall forges a server certificate signed by its Forward Trust CA, enabling it to decrypt and inspect the traffic between the internal client and the external server.

Key Configuration Components in PAN-OS:

• Forward Trust Certificate: (Device > Certificate Management > Certificates) This is the CA certificate the firewall uses to sign the forged server certificates. It must be trusted by internal clients. This can be a self-signed CA generated on the firewall or an intermediate CA signed by an internal enterprise CA.
• Forward Untrust Certificate: (Device > Certificate Management > Certificates) This certificate is presented to clients if the original server certificate from the external server is invalid (e.g., expired, self-signed by an untrusted CA, wrong hostname). This typically results in a browser warning, alerting the user to a potential issue with the destination site.
• Decryption Profile: (Objects > Decryption > Decryption Profile) Controls various SSL/TLS parameters for decrypted sessions, such as:
  • SSL Protocol Settings: Min/Max versions (e.g., TLS 1.2, TLS 1.3).
  • Certificate Checks: Block sessions with expired certificates, untrusted issuers, etc.
  • Unsupported Modes: Actions for unsupported cipher suites or protocol versions.
  • Hardware Security Module (HSM) usage.
• Decryption Policy Rule: (Policies > Decryption) Defines which traffic to decrypt. Match criteria include source/destination zones, addresses, users, services, and URLs. The action is typically "decrypt".

! Example: Basic Decryption Policy Rule for SSL Forward Proxy
! In PAN-OS GUI: Policies > Decryption > Add

Name: Decrypt-Outbound-Web
Source Zones: [trust-zone]
Source Addresses: [internal-networks]
Source Users: [any]
Destination Zones: [untrust-zone]
Destination Addresses: [any]
Service/URL Category: [any] ! Best practice: Be more specific, e.g., URL categories known to be risky or needing inspection
Action: Decrypt
Decryption Profile: [your-ssl-forward-proxy-profile]
Type: ssl-forward-proxy
        

Considerations and Limitations:

• Certificate Pinning: Applications that use certificate pinning (hardcoding the expected server certificate or public key) will break if SSL Forward Proxy is attempted. The forged certificate from the firewall will not match the pinned certificate. Such applications/sites often need to be excluded from decryption. (See Decryption Exclusions section).
• Client Authentication Certificates: If an external service requires the client to present a certificate for authentication, SSL Forward Proxy can interfere. PAN-OS has options to handle this, such as "Block sessions with client authentication," or it may require exclusion.
• Unsupported Cipher Suites/Protocols: If the client and server negotiate a cipher suite or TLS version that the firewall does not support for decryption, the session might be blocked or passed through undecrypted, depending on the Decryption Profile settings. PAN-OS regularly updates support for new ciphers.
• Performance Impact: Decryption is CPU-intensive. Sizing the firewall appropriately and understanding the performance implications are crucial (See Performance & Sizing section).
• Privacy Concerns: Decrypting user traffic raises privacy considerations. Organizations must have clear policies and inform users about traffic inspection. Certain categories of traffic (e.g., financial, healthcare) are often excluded from decryption for privacy reasons.
• High Availability (HA) Limitations: SSL Forward Proxy decrypted sessions are generally not synchronized between HA peers in an Active/Passive cluster. A failover event will typically cause existing decrypted sessions to be dropped and require re-establishment. This is because the session keys and dynamic certificate information are unique to the firewall processing the session.
• QoS and DSCP Markings: Traffic undergoing proxy-based decryption (like SSL Forward Proxy) might lose its original DSCP markings. PAN-OS might not be able to re-apply or honor these markings on proxied traffic in the same way as non-proxied traffic. Specific PAN-OS versions and configurations might offer improvements here, so always consult current documentation.

SSL Inbound Inspection (Inbound SSL/TLS Decryption)

Use Case: SSL Inbound Inspection is used to decrypt and inspect SSL/TLS traffic destined for internal servers (e.g., corporate web servers, application servers, email servers) that are protected by the Palo Alto Networks firewall. This allows the firewall to identify and block threats targeting these servers before they reach the application, ensuring that encrypted traffic does not bypass security measures.

How SSL Inbound Inspection Works in PAN-OS:

For SSL Inbound Inspection, the firewall needs access to the server's private key and certificate. The process is as follows:

1. Import Server Certificate and Private Key: The administrator imports the SSL certificate (and its corresponding private key) of the internal server that needs protection onto the Palo Alto Networks firewall. This is done under Device > Certificate Management > Certificates.
2. Client Initiates Connection: An external client initiates an SSL/TLS session to an internal server (e.g., https://yourcompany.com). The traffic is typically routed to the firewall's external interface, often via a Destination NAT (DNAT) rule if the server is in a private IP space.
3. Firewall Interception and Decryption: The firewall, based on a matching Decryption Policy rule (type: ssl-inbound-inspection), intercepts the incoming TLS connection. Using the imported server certificate and its private key, the firewall decrypts the client's traffic.
4. Inspection: The decrypted cleartext traffic is passed through the firewall's security engines (App-ID, Content-ID: Threat Prevention, URL Filtering if applicable, WildFire, DLP).
5. Re-encryption and Forwarding to Server: After inspection, the firewall re-encrypts the traffic (or establishes a new TLS session if necessary, though often it passes the decrypted traffic to the server if the server is in a secure segment and configured to accept HTTP) and forwards it to the actual internal server. If re-encrypting, it typically uses the server's original certificate.

PAN-OS also supports Session Key Forwarding for SSL Inbound Inspection in specific scenarios (e.g., with certain load balancers or server configurations that can export session keys). However, the most common method involves importing the server's private key.

Detailed sequence of SSL Inbound Inspection. The firewall uses the imported server private key to decrypt, inspect, and then re-encrypt traffic destined for an internal server.

Key Configuration Components in PAN-OS:

• Server Certificate and Private Key: (Device > Certificate Management > Certificates) The SSL certificate and its corresponding private key for each internal server to be protected must be imported into the firewall. The private key must be exportable from the server/CA.
  Gotcha! (Palo Alto Networks): One of the most critical requirements for SSL Inbound Inspection is obtaining and securely importing the server's private key. If the private key is compromised, the security of the SSL sessions is at risk. Ensure proper key management practices. Using an HSM can enhance private key security.
• Decryption Profile: (Objects > Decryption > Decryption Profile) Similar to SSL Forward Proxy, this profile controls SSL/TLS parameters (protocol versions, cipher strengths, certificate checks) for inbound sessions. It can be tailored for server-side requirements.
• Decryption Policy Rule: (Policies > Decryption) Defines which inbound traffic to decrypt. Match criteria include source zones (e.g., untrust), destination addresses (e.g., public IP of the server, often a NATed IP), and services (e.g., HTTPS). The action is "decrypt," and the type is "ssl-inbound-inspection." The rule must also specify the server certificate to use for decryption.

  ! Example: Basic Decryption Policy Rule for SSL Inbound Inspection
  ! In PAN-OS GUI: Policies > Decryption > Add
  
  Name: Decrypt-Inbound-WebServer
  Source Zones: [untrust-zone]
  Source Addresses: [any]
  Source Users: [any]
  Destination Zones: [dmz-zone] ! Or wherever the server resides post-NAT
  Destination Addresses: [public-ip-of-webserver]
  Service/URL Category: [service-https]
  Action: Decrypt
  Decryption Profile: [your-ssl-inbound-inspection-profile]
  Type: ssl-inbound-inspection
  Certificate: [your-imported-server-certificate-name]
                  

• NAT Policy (Optional but Common): (Policies > NAT > Destination NAT) If internal servers use private IP addresses, a DNAT policy is required to translate the public destination IP address (accessed by external clients) to the server's private IP address. The Decryption policy often matches on the post-NAT (private) address and zone.

Considerations and Limitations:

• Private Key Management: Securely managing server private keys on the firewall is paramount. Access to the firewall's management interface must be tightly controlled. HSM integration is recommended for enhanced key protection.
• Certificate Pinning by Clients: If clients use certificate pinning for your internal servers, SSL Inbound Inspection (where the firewall effectively re-signs or proxies the connection) could break this, though typically the firewall uses the *actual* server certificate. The primary concern is ensuring the client receives the exact certificate it expects. This is generally less of an issue for Inbound Inspection than for Forward Proxy, as the firewall presents the legitimate server certificate.
• Client Authentication Certificates: If clients are authenticating to your server using their own certificates, SSL Inbound Inspection needs to be configured to handle this correctly. PAN-OS typically allows client certificates to pass through.
• Unsupported Cipher Suites/Protocols: Similar to Forward Proxy, if a client negotiates a cipher or protocol version not supported by the firewall for decryption, the session might be blocked or passed undecrypted, based on the Decryption Profile.
• Performance Impact: Decrypting inbound traffic also consumes firewall resources. Server capacity and firewall sizing are important.
• Perfect Forward Secrecy (PFS): Ciphers that provide PFS (e.g., ECDHE) mean that even if a server's long-term private key is compromised, past session keys cannot be derived. When the firewall performs SSL Inbound Inspection by holding the server's private key, it effectively terminates the TLS session and establishes a new one (or forwards decrypted traffic). The firewall itself must support these ciphers.
• High Availability (HA) Limitations: Similar to SSL Forward Proxy, SSL Inbound Inspection decrypted sessions are not typically synchronized between HA peers in Active/Passive. A failover can cause session drops. This is a significant consideration for critical services. For environments requiring seamless failover for decrypted sessions, alternative architectures or specific PAN-OS features (if available for specific scenarios and versions) may need evaluation.
• QoS and DSCP Markings: As with other proxy-based operations, original DSCP markings might not be preserved through the SSL Inbound Inspection process.

Certificates & PKI in PAN-OS for Decryption

Proper certificate management is the cornerstone of successful SSL/TLS decryption with Palo Alto Networks firewalls. PAN-OS provides comprehensive tools for managing certificates, Certificate Authorities (CAs), and related Public Key Infrastructure (PKI) components.

Navigate to Device > Certificate Management in the PAN-OS GUI to manage these elements.

Key Certificate Types and Their Roles in Decryption:

• Forward Trust Certificate (for SSL Forward Proxy):
  • Purpose: Used by the firewall to sign the dynamically forged server certificates it presents to clients during SSL Forward Proxy.
  • Requirement: This CA certificate (or its issuing CA if it's an intermediate CA) MUST be installed and trusted on all client endpoint devices (in their browser/OS trust store).
  • Generation: Can be a self-signed CA certificate generated directly on the PAN-OS firewall, or an intermediate CA certificate signed by an existing internal enterprise CA. Using an enterprise CA often simplifies deployment as clients may already trust the root CA.
  • Security: The private key of this CA is highly sensitive.
• Forward Untrust Certificate (for SSL Forward Proxy):
  • Purpose: Presented to the client when the firewall intercepts an SSL/TLS session for a server whose original certificate is invalid or untrusted (e.g., expired, self-signed by an unknown CA, CN mismatch).
  • Effect: Causes a prominent browser error, alerting the user to the problem with the remote server's certificate. This is an important security feature.
  • Default: PAN-OS provides a default Forward Untrust certificate, but a custom one can be configured.
• Server Certificates (for SSL Inbound Inspection):
  • Purpose: The actual SSL certificate (and its private key) of an internal server (e.g., web server) that you want to protect with SSL Inbound Inspection.
  • Requirement: Must be imported into the firewall along with its private key. The private key MUST be marked as exportable when the certificate was created/issued.
  • Usage: The firewall uses this key pair to decrypt traffic destined for the internal server.
• Firewall's Own Device Certificates:
  • Purpose: Used for services hosted on the firewall itself, such as the management interface (HTTPS), GlobalProtect portals/gateways, and Captive Portal.
  • Relevance to Decryption: Not directly used for SSL Forward Proxy or Inbound Inspection of *transiting* traffic, but essential for securing firewall-hosted services. It's important to use certificates signed by a trusted CA for these services to avoid browser warnings for administrators or users.
• Trusted Certificate Authorities (CAs):
  • Purpose: PAN-OS maintains a list of pre-installed public CAs that are trusted by default (similar to browser trust stores). These are used to validate the authenticity of certificates presented by external servers during SSL Forward Proxy.
  • Management: You can add your own enterprise CAs to this list if your internal servers or external partners use certificates signed by an internal CA. (Device > Certificate Management > Certificate Profile).

Certificate Revocation Checking:

PAN-OS can check the revocation status of certificates it encounters to ensure they haven't been compromised or revoked by the issuing CA. This is configured in Certificate Profiles (Device > Certificate Management > Certificate Profile).

• OCSP (Online Certificate Status Protocol): The firewall queries an OCSP responder (often specified in the certificate's AIA extension) to get real-time status.
• CRL (Certificate Revocation List): The firewall downloads and caches CRLs from distribution points (specified in the certificate's CDP extension).

Configuring OCSP/CRL checking is a best practice for both SSL Forward Proxy (validating external server certs) and SSL Inbound Inspection (validating client certs if client authentication is used).

Generating a Self-Signed CA for Forward Trust on PAN-OS:

1. Navigate to Device > Certificate Management > Certificates .
2. Click Generate .
3. Certificate Name: e.g., "Forward-Trust-CA".
4. Common Name (CN): A descriptive name, e.g., "MyCompany Internal Forward Trust CA".
5. Select Certificate Authority (CA) checkbox.
6. Configure other parameters like key size, digest, expiry.
7. Click Generate .
8. Once generated, select this certificate in your SSL Forward Proxy Decryption Profile.
9. Export this CA certificate ( without the private key ) and deploy it to all client trust stores.

Importing a Server Certificate for SSL Inbound Inspection:

1. Navigate to Device > Certificate Management > Certificates .
2. Click Import .
3. Certificate Name: e.g., "WebServer-Cert".
4. Certificate File: Browse to your server's certificate file (e.g., .pem, .pfx, .p12).
   • If using .pfx or .p12, it includes the private key and you'll be prompted for its password.
   • If using .pem, you'll import the certificate file and then separately import the private key file.
5. If importing key separately: Private Key File: Browse to the private key file. Enter passphrase if encrypted.
6. Click OK .
7. Select this imported certificate in your SSL Inbound Inspection Decryption Policy rule.

PAN-OS Decryption Policies and Profiles

Decryption Policies and Decryption Profiles are the core components used to control how and what traffic the Palo Alto Networks firewall decrypts. They provide granular control over the decryption process.

Decryption Policies

Decryption Policies define *which* traffic should be subjected to decryption. They are configured under Policies > Decryption and are evaluated similarly to Security Policy rules: top-down, first match.

A Decryption Policy rule consists of:

• General Information: Name, Description, Tags, Audit Comment.
• Source: Source Zone, Source Address (objects, groups, IP netmasks), Source User (User-ID).
• Destination: Destination Zone, Destination Address.
• Service/URL Category:
  • Service: Predefined (e.g., `service-https`, `service-ssh`) or custom services/service groups.
  • URL Category: For SSL Forward Proxy, you can specify URL categories to decrypt (e.g., "malware", "phishing", "web-based-email") or exclude (e.g., "financial-services", "health-and-medicine"). Requires PAN-DB license.
• Action & Type:
  • No Decrypt (Default): Traffic matching this rule will not be decrypted. This is often used for explicit exclusions.
  • Decrypt: Traffic matching this rule will be decrypted.
    • Type (for Decrypt action):
      • ssl-forward-proxy : For outbound SSL/TLS decryption.
      • ssl-inbound-inspection : For inbound SSL/TLS decryption. Requires specifying the Server Certificate .
      • ssh-proxy : For SSH decryption.
  • Block: Traffic matching this rule will be blocked without decryption attempt.
• Profile (for Decrypt action): Specifies the Decryption Profile to apply to the decrypted traffic. This profile controls the parameters of the decryption (e.g., protocol versions, certificate checks).
• Log Forwarding: Specifies a Log Forwarding Profile to send decryption logs to syslog, Panorama, etc.

Example Decryption Policy Strategy:

1. Rule 1 (High Priority Exclusions): URL Categories like Financial Services, Health and Medicine. Action: No Decrypt. Reason: Privacy, compliance, or sites known to break with decryption.
2. Rule 2 (Known Problematic Sites/Apps): Specific FQDNs or App-IDs that use certificate pinning or have other issues. Action: No Decrypt. Reason: Ensure application functionality.
3. Rule 3 (Broad Decryption): Decrypt general web categories (e.g., social-networking, streaming-media, high-risk categories). Action: Decrypt (Type: ssl-forward-proxy). Reason: Maximize visibility and threat prevention.
4. Rule 4 (Inbound Server Protection): Decrypt traffic to specific internal servers. Action: Decrypt (Type: ssl-inbound-inspection, specify Server Certificate). Reason: Protect internal assets.
5. Rule 5 (Default - Implicit): PAN-OS has an implicit final rule of "No Decrypt" if no explicit rule is matched. It is best practice to have an explicit "No Decrypt Any" rule at the bottom if your policy is to decrypt only specific traffic.

Decryption Profiles

Decryption Profiles define *how* the matched traffic should be decrypted. They are configured under Objects > Decryption > Decryption Profile and are referenced by Decryption Policy rules.

Key settings within a Decryption Profile (can vary slightly based on PAN-OS version):

• SSL Forward Proxy Tab / SSL Inbound Inspection Tab (options may be shared or specific):
  • Block sessions with expired certificates: Blocks if the server's certificate is expired.
  • Block sessions with untrusted issuers: Blocks if the server's certificate is signed by a CA not in the firewall's trusted CA list.
  • Block sessions with client authentication: For SSL Forward Proxy, this blocks sites requiring client cert auth (can break some B2B sites). For Inbound, determines how client certs are handled.
  • Block sessions if resources not available: Blocks if firewall decryption resources are exhausted. (Use with caution).
  • Block sessions if HSM not available: If an HSM is configured for private key operations, block if the HSM is unreachable.
  • Unsupported Protocol Versions: Action (e.g., block or no-decrypt) for SSL/TLS versions the firewall doesn't support for decryption (e.g., SSLv2, SSLv3).
    CRITICAL (Palo Alto Networks): Always block outdated and insecure protocols like SSLv2 and SSLv3.
  • Unsupported Cipher Suites: Action for cipher suites the firewall doesn't support for decryption.
  • Certificate Status Check Failure: Action if OCSP/CRL check fails or indicates revoked certificate.
• SSH Proxy Tab:
  • Block sessions if resources not available.
  • Block sessions if HSM not available.
• No Proxy Tab (for controlling pass-through traffic behavior):
  • Controls checks even for traffic not actively proxied/decrypted by the firewall but still passing through it (e.g., for basic certificate validation if not decrypting).

It's common to have multiple Decryption Profiles tailored for different scenarios (e.g., a lenient profile for some sites, a strict one for general browsing, a specific one for inbound servers).

SSH Proxy (SSH Decryption and Control)

Use Case: SSH Proxy on Palo Alto Networks firewalls allows for the decryption and inspection of Secure Shell (SSH) traffic. The primary goals are to control and monitor SSH sessions, prevent unauthorized activities like SSH tunneling (port forwarding), and potentially inspect for malicious commands or file transfers within interactive SSH sessions if further content inspection capabilities are applied.

How SSH Proxy Works in PAN-OS:

Similar to SSL Forward Proxy, the firewall acts as a "man-in-the-middle" for SSH connections:

1. Client Initiates SSH Connection: A user or process initiates an SSH connection to an SSH server.
2. Firewall Interception: Based on a matching Decryption Policy rule (type: ssh-proxy), the firewall intercepts the SSH connection.
3. Firewall-Server Session: The firewall establishes its own SSH session with the destination SSH server. It receives the server's host key.
4. Firewall-Client Session & Host Key Handling: The firewall establishes an SSH session with the client.
   • By default, the firewall presents its own unique SSH host key to the client. This key is generated by the firewall (typically one per firewall or per VSYS). If this key changes (e.g., after a firewall reboot, if the key is not persistent, or if a different firewall in an HA pair handles a re-established session), clients will receive a "host key changed" warning, which can be disruptive.
   • Alternatively, for specific servers, you can import the actual server's host key onto the firewall and configure the SSH Proxy to present that specific key to the client when proxying to that server. This avoids the client-side host key warning but requires managing these keys on the firewall.
5. Decryption and Inspection: The firewall now sits in the middle of two SSH connections. It decrypts traffic from the client, inspects it, and re-encrypts it for the server, and vice-versa. Inspection focuses on:
   • SSH Channel Control: PAN-OS can identify and control different types of SSH channels, such as:
     • ssh-pty (interactive shell)
     • ssh-exec (remote command execution)
     • scp (secure copy)
     • sftp (SSH file transfer protocol)
     • ssh-tunnel (port forwarding - X11, local, remote)
   • Security Policy Enforcement: Based on the identified SSH sub-application (e.g., ssh-tunnel ), Security Policies can be applied to allow or deny specific SSH functionalities. For example, allow ssh-pty but deny ssh-tunnel .

Sequence of SSH Proxy operation. The firewall intercepts the SSH connection, manages host keys, and inspects decrypted channel data, allowing for granular control over SSH functionalities like tunneling.

Key Configuration Components in PAN-OS:

• Decryption Profile (SSH Proxy Tab): (Objects > Decryption > Decryption Profile)
  • Block sessions if resources not available.
  • Block sessions if HSM not available (less common for SSH proxy unless specific key operations are offloaded).
• Decryption Policy Rule: (Policies > Decryption)
  • Match criteria: Source/Destination Zones, Addresses, Users, Service (typically service-ssh ).
  • Action: Decrypt .
  • Type: ssh-proxy .
  • Profile: Select your SSH Decryption Profile.
• Security Policy Rules: (Policies > Security) Crucial for controlling SSH sub-applications identified by App-ID *after* decryption.

  ! Example Security Policy to allow interactive SSH but block SSH tunneling
  ! Assumes SSH traffic is already being decrypted by an SSH Proxy Decryption Policy
  
  Rule 1:
  Name: Allow-Interactive-SSH
  Source Zones: [trust-zone]
  Destination Zones: [untrust-zone / dmz-zone]
  Application: [ssh-pty, ssh-exec, sftp, scp] ! Or just 'ssh' if you allow all non-tunneling
  Service: [application-default]
  Action: Allow
  
  Rule 2:
  Name: Block-SSH-Tunneling
  Source Zones: [trust-zone]
  Destination Zones: [untrust-zone / dmz-zone]
  Application: [ssh-tunnel]
  Service: [application-default]
  Action: Deny
                  

• Server Host Keys (Optional): (Device > Certificate Management > SSH Host Keys) You can import the public host keys of specific internal SSH servers. Then, in the Decryption Policy rule for SSH Proxy, you can specify this "Server Host Key" to be presented to clients connecting to that server, avoiding the "man-in-the-middle" host key warning.
• Firewall SSH Host Key: The firewall generates its own host key. This can be managed under Device > Setup > Management > SSH Host Key Management (though this primarily pertains to the firewall's own SSH management service, the proxy may use a similar mechanism or a dynamically generated one). Persistence of this key across reboots is important to avoid client warnings.

Limitations and Considerations:

• No Decryption of Tunneled Data: The SSH Proxy itself does *not* decrypt the data *within* an established SSH tunnel (e.g., tunneled RDP, web traffic). It can identify and block the creation of the tunnel itself ( ssh-tunnel application), but not inspect the payload flowing through an allowed tunnel.
  CRITICAL (Palo Alto Networks): To prevent unauthorized data exfiltration or C2 communication via SSH tunnels, you MUST have Security Policy rules that explicitly deny the `ssh-tunnel` application for traffic that has been decrypted by SSH Proxy.
• Authentication Methods:
  • SSH Proxy primarily supports username/password authentication .
  • Public Key Authentication (PKA): Generally not supported through SSH Proxy. If PKA is required, those SSH sessions typically need to be excluded from SSH decryption. Some specific PAN-OS versions or configurations might offer limited PKA passthrough, but it's not the standard behavior. Always verify with current Palo Alto Networks documentation.
  • Other interactive methods like Kerberos or keyboard-interactive (e.g., for MFA prompts) might have varying degrees of support or may require passthrough.
• Host Key Warnings: As mentioned, if the firewall presents its own host key, clients might receive warnings if the key changes or if they have previously connected to the server directly. Using imported server host keys can mitigate this for specific destinations.
• Performance Impact: Like SSL decryption, SSH decryption consumes firewall resources.
• High Availability (HA) Limitations: Decrypted SSH sessions are generally not synchronized between HA peers. A failover may drop active SSH sessions being proxied.
• QoS and DSCP Markings: Proxied SSH traffic may not retain original DSCP markings.
• Command/File Content Inspection: While SSH Proxy decrypts the SSH PTY channel, deep inspection of commands executed or files transferred (beyond identifying scp or sftp ) typically requires integration with other features or advanced threat signatures if available for specific patterns. The primary strength is controlling *types* of SSH channels.

Decryption Exclusions & Troubleshooting in PAN-OS

While decrypting traffic is crucial for security, there are scenarios where decryption is not possible, not desirable, or causes issues. Palo Alto Networks firewalls provide mechanisms to exclude specific traffic from decryption and robust tools for troubleshooting decryption problems.

Reasons for Decryption Exclusions:

• Technical Limitations:
  • Certificate Pinning: Applications or websites that embed (pin) the expected server certificate or public key will reject the firewall's forged certificate in SSL Forward Proxy.
  • Client Certificate Authentication: Some applications require clients to present a certificate for authentication, which can be disrupted by SSL Forward Proxy. While PAN-OS has some handling for this, exclusion is sometimes simpler.
  • Mutual TLS Authentication (mTLS): Both client and server authenticate each other using certificates. Decryption can interfere with this complex handshake.
  • Unsupported Protocols/Ciphers: Applications using proprietary encryption methods, or very old/new SSL/TLS versions or cipher suites not yet supported for decryption by PAN-OS.
  • Non-Standard TLS Usage: Applications that use TLS in non-standard ways (e.g., EAP-TLS within a PEAP tunnel for Wi-Fi authentication).
• Policy and Privacy Reasons:
  • Sensitive Data: Financial transactions (banking sites), healthcare information (patient portals), legal communications. Organizations may choose not to decrypt these due to privacy regulations (e.g., GDPR, HIPAA) or internal policy.
  • User Experience: Some legitimate sites or applications might perform poorly or break in subtle ways when decrypted, even if they don't use pinning.
• Resource Management: Excluding high-volume, low-risk trusted traffic (e.g., streaming services from known benign sources, OS updates from trusted vendors) can help conserve firewall decryption resources.

Configuring Decryption Exclusions:

Exclusions are typically configured using Decryption Policy rules with an action of "No Decrypt" . These rules should be placed higher in the policy list than broader decryption rules.

Common criteria for "No Decrypt" rules:

• URL Category: E.g., "financial-services", "health-and-medicine". (Requires PAN-DB license).

  ! Example: No Decrypt rule for Financial Services URL Category
  ! In PAN-OS GUI: Policies > Decryption > Add
  Name: NoDecrypt-Financial
  Source Zones: [trust-zone]
  Destination Zones: [untrust-zone]
  URL Category: [financial-services]
  Action: No Decrypt
                  

• Destination FQDNs/IPs: Create Address Objects or FQDN Objects for specific problematic domains (e.g., app1.example.com , updates.vendor.com ).
• Application: Some App-IDs might be inherently problematic with decryption (though this is less common than URL-based exclusions, as App-ID often relies on decrypted content for accuracy).
• Source/Destination IP Addresses: For specific servers or client subnets.
• Service: Exclude non-web SSL/TLS traffic if it's known to cause issues (e.g., custom SSL-based applications on non-standard ports).

PAN-OS also offers a "SSL Decryption Exclusion" list (Device > Setup > Content-ID > SSL Decryption Exclusion on older versions, or managed via Application Override/custom App-ID on newer versions for some scenarios) for specific server certificates that should not be decrypted (e.g., if they are known to be pinned). However, using "No Decrypt" Decryption Policy rules based on FQDN or URL category is generally more flexible and common.

Troubleshooting Decryption Issues:

When decryption is enabled, issues can manifest as broken websites, application failures, or certificate errors on client machines.

1. Client-Side Checks:

• Browser Certificate Errors:
  • "Your connection is not private" / "SEC_ERROR_UNKNOWN_ISSUER": Often means the client doesn't trust the firewall's Forward Trust CA (for SSL Forward Proxy). Ensure the Forward Trust CA cert is correctly installed in the client's trust store.
  • "Certificate Name Mismatch": The CN/SAN on the forged certificate doesn't match the requested URL. Check SNI handling and Decryption Profile.
  • If using Forward Untrust, the warning is expected if the original server cert is bad. Investigate the original server cert.
• Application-Specific Errors: Applications might log errors or fail to connect. Check application logs.

2. Firewall Logs:

• Decryption Logs: (Monitor > Logs > Decryption) The most important log type for decryption issues. Provides details on:
  • Session details (source/dest IP, port, user).
  • Decryption policy rule matched.
  • Decryption type (e.g., ssl-forward-proxy, ssl-inbound-inspection).
  • Certificate details (issuer, subject).
  • Errors encountered (e.g., "Handshake error", "Untrusted issuer", "Unsupported cipher", "Certificate validation error", "Session terminated: Client cert required").
  • Action taken (e.g., decrypted, not decrypted, blocked).
  Filter these logs extensively to find relevant sessions.
• Traffic Logs: (Monitor > Logs > Traffic) Shows if sessions are allowed or denied by Security Policy, and if decryption was attempted ("decrypted" flag).
• URL Filtering Logs: (Monitor > Logs > URL Filtering) If decryption is working, this log will show the full URL path, not just the FQDN for HTTPS sites.
• Threat Logs: (Monitor > Logs > Threat) Shows if threats are being detected in decrypted traffic.

3. Firewall CLI Commands:

Useful for real-time troubleshooting and diagnostics:

• show counter global filter aspect decryption : Shows various decryption-related counters, including errors, unsupported versions/ciphers, resource limitations.

  > show counter global filter aspect decryption
  
  Global counters:
  Elapsed time:      12345.678 seconds
  
  name                                  value     rate severity  category  aspect    description
  ------------------------------------------------------------------------------------------------------------------------------------
  decrypt_sess_proxy_ssl                15000     1    info      flow      decryption Sessions that are SSL proxy
  decrypt_sess_inspect_ssl              200       0    info      flow      decryption Sessions that are SSL inspected
  decrypt_cert_cache_hit                12000     1    info      flow      decryption Certificate cache hit
  decrypt_cert_cache_miss               3000      0    info      flow      decryption Certificate cache miss
  decrypt_sess_unsupport_ver            50        0    warn      flow      decryption Sessions that are unsupported version
  decrypt_sess_unsupport_cipher         20        0    warn      flow      decryption Sessions that are unsupported cipher
  decrypt_sess_err_ssl_srv_unavail      5         0    error     flow      decryption SSL server unavailable errors
  ...many more counters...
                  

• show session id <session_id> : Shows details for a specific session, including whether it's decrypted and any relevant flags.
• debug dataplane packet-diag set filter match ... and debug dataplane packet-diag set log ... : Advanced packet-level debugging to trace packet flow and processing, including decryption stages. Use with caution as it's resource-intensive.
• show_decryption_policy_received_cert <server_ip> <server_port> : (May vary by PAN-OS version or require specific debug modes) Can show the certificate received by the firewall from the actual server, useful for diagnosing certificate issues.
• test decryption-policy-match source <ip> destination <ip> ... : Tests which decryption policy rule a hypothetical session would match.
• show system setting ssl-decrypt certificate-summary : Shows a summary of certificates used for decryption.

4. Packet Captures (PCAPs):

• Capture traffic on the client, on the firewall (ingress/egress interfaces), and on the server.
• Analyze PCAPs in Wireshark to inspect TLS handshakes, certificate exchanges, and identify where communication breaks down.
  • Look for TLS alerts.
  • Examine the certificates being exchanged.

PAN-OS Decryption Performance & Sizing

Enabling SSL/TLS and SSH decryption on Palo Alto Networks firewalls significantly enhances security visibility but also imposes additional processing load. Proper sizing of the firewall and understanding performance implications are critical for a successful decryption deployment.

Factors Affecting Decryption Performance:

• Volume of Encrypted Traffic: The percentage of total traffic that is SSL/TLS or SSH and is targeted for decryption. Modern networks often see 70-90%+ of web traffic being encrypted.
• Throughput of Decrypted Traffic: The actual bandwidth of traffic being actively decrypted and re-encrypted.
• Connections Per Second (CPS) for Decrypted Traffic: The rate at which new encrypted sessions needing decryption are established. Handshake operations (key exchange, certificate validation) are particularly CPU-intensive.
• Concurrent Decrypted Sessions: The total number of active sessions being decrypted simultaneously. Each session consumes memory and CPU.
• Cipher Suite Complexity: More complex cryptographic algorithms (e.g., those involving longer keys or more intensive computations like certain elliptic curve ciphers) can consume more CPU resources. RSA handshakes are generally more intensive than ECDHE.
• Certificate Operations: For SSL Forward Proxy, forging certificates dynamically for each new server takes CPU. For SSL Inbound Inspection, using the private key for decryption also consumes CPU. OCSP/CRL checks add overhead.
• Firewall Model and Hardware Resources:
  • CPU: The primary resource for cryptographic operations. Higher-end PA-Series models have more powerful CPUs and, in some cases, dedicated hardware acceleration for crypto.
  • Memory: Used to store session state, certificate caches, etc.
  • Data Plane Architecture: The SP3 (Single-Pass Parallel Processing) architecture is designed to handle multiple security functions efficiently, but decryption is still a demanding task. Some platforms (e.g., PA-5400 Series, PA-7000 Series) have dedicated crypto acceleration hardware (often referred to as LSC - Logic Specific Crypto or similar).
• Other Security Services Enabled: Decryption allows other services (Threat Prevention, WildFire, DLP, URL Filtering) to inspect the cleartext traffic. These services also consume resources. The overall load is cumulative.

Sizing Considerations:

1. Baseline Current Traffic: Understand your current network traffic profile: total throughput, connections per second, percentage of SSL/TLS traffic. Use firewall reports, NetFlow, or other monitoring tools.
2. Estimate Decryption Scope: Determine how much of the SSL/TLS traffic you plan to decrypt. A phased approach, starting with high-risk categories or specific user groups, is often recommended.
3. Consult Palo Alto Networks Datasheets: Review the datasheet for your target firewall model(s). Look for metrics like:
   • SSL Decryption Throughput (or similar, e.g., "Threat Prevention Throughput (HTTP/SSL traffic with Decryption)")
   • SSL Decryption Connections Per Second
   • SSL Decryption Concurrent Sessions
   These numbers are typically lower than the raw firewall throughput.
4. Apply a Derating Factor: Datasheet numbers are often based on ideal conditions. In real-world deployments with multiple security services enabled, the actual performance may be lower. It's common practice to derate datasheet values (e.g., by 20-50%) depending on complexity and risk tolerance.
5. Consider Future Growth: Plan for future increases in traffic volume, encrypted traffic percentage, and user count.
6. Use Palo Alto Networks Sizing Tools/Consultants: For complex environments or critical deployments, leverage Palo Alto Networks sizing tools (if available to partners/customers) or consult with Palo Alto Networks sales engineers or professional services. They can help model performance based on your specific requirements.
7. Hardware Refresh Cycles: If existing hardware is old, enabling widespread decryption might necessitate a hardware upgrade to a newer model with better decryption capabilities.
8. High Availability (HA): In an Active/Passive HA pair, the active firewall handles all decryption. Ensure it's sized adequately. Active/Active HA can distribute load, but has its own complexities, especially with session state for decrypted traffic.

Monitoring Decryption Performance:

After deploying decryption, continuously monitor its impact:

• Firewall Dashboard: Check CPU utilization (management plane and data plane), session count, and throughput. High sustained CPU on data plane cores is a key indicator of potential overload.
• ACC (Application Command Center): Monitor traffic trends, identify top applications using SSL/TLS, and see how much traffic is being decrypted.
• Session Browser: Look for session setup times and any unusual session termination reasons.
• CLI Commands:
  • show running resource-monitor : Shows real-time CPU utilization per core and other resource metrics.

    > show running resource-monitor
    CPU Load (Last 1 min):
    Core  0: 15%    Core  1: 22%
    Core  2: 18%    Core  3: 75%  <-- High CPU on this core might indicate heavy decryption load
    ...
                        

  • show counter global filter aspect decryption : As mentioned in troubleshooting, provides counters for decrypted sessions, errors, resource issues. Monitor these for unexpected spikes.
  • show session info : Shows current active sessions, including decrypted ones.
• SNMP Monitoring: Use SNMP to poll CPU, memory, session counts, and interface statistics. Set thresholds and alerts.
• Panorama: If using Panorama, leverage its aggregated reporting and logging to monitor decryption performance across multiple firewalls.

Optimizing Decryption Performance:

• Selective Decryption: Don't decrypt everything. Use Decryption Policies to strategically decrypt only what's necessary (e.g., risky URL categories, untrusted traffic, specific applications) and exclude known-good, high-volume, or problematic traffic.
• Hardware Upgrades: If performance is consistently an issue, consider upgrading to a more powerful firewall model, especially one with dedicated crypto acceleration.
• Session Timeouts: Ensure appropriate SSL/TLS session timeouts are configured (in Decryption Profiles or globally) to free up resources from idle sessions.
• Certificate Caching: PAN-OS caches certificates to reduce the overhead of fetching/validating them repeatedly. Ensure this is functioning effectively.
• TLS 1.3 Adoption: TLS 1.3 generally offers performance improvements in its handshake process compared to older TLS versions. Ensure your Decryption Profiles allow and prefer TLS 1.3 where supported by clients and servers.

HSM Integration for Enhanced Private Key Security in PAN-OS

For organizations with stringent security requirements for managing cryptographic keys, Palo Alto Networks firewalls support integration with Hardware Security Modules (HSMs). An HSM is a dedicated hardware device designed to securely generate, store, and manage digital keys, protecting them from unauthorized access, theft, or misuse.

Why Use HSMs with Palo Alto Networks Decryption?

The primary use case for HSM integration in the context of decryption is to protect the private keys used by the firewall:

• SSL Forward Proxy (Forward Trust CA Key): The private key of the Forward Trust CA certificate is extremely sensitive. If compromised, an attacker could potentially impersonate any website to internal users and intercept their encrypted traffic. Storing this key on an HSM adds a strong layer of protection.
• SSL Inbound Inspection (Server Private Keys): The private keys of your internal servers (e.g., web servers, application servers) are critical assets. Storing these keys on an HSM prevents them from being directly accessible on the firewall's file system, even by privileged administrators. Cryptographic operations involving these keys (like decrypting client sessions) are performed within the secure boundary of the HSM.
• SSH Proxy (Firewall's SSH Host Key - Less Common): While theoretically possible, protecting the firewall's own SSH host key (used when it proxies SSH connections and doesn't use an imported server host key) with an HSM is a less common use case compared to SSL keys.

Benefits of HSM Integration:

• Enhanced Key Security: HSMs provide FIPS 140-2 Level 2, 3, or even 4 certified tamper-resistant hardware for key storage and operations. Private keys never leave the HSM in plaintext.
• Compliance: Helps meet regulatory and compliance mandates (e.g., PCI DSS, GDPR, HIPAA) that require strong key protection and management.
• Centralized Key Management: For organizations with multiple firewalls or other systems needing secure key storage, HSMs can offer a centralized and consistent approach.
• Strong Access Controls: HSMs typically have robust authentication and authorization mechanisms to control access to keys and cryptographic functions.

Supported HSM Vendors and Models:

Palo Alto Networks typically partners with leading HSM vendors. Common examples include:

• Thales (formerly Gemalto/SafeNet): Luna Network HSMs, ProtectServer HSMs.
• nCipher (formerly part of Thales, now Entrust): nShield Connect HSMs.

The specific list of supported HSM models and required firmware versions can change. Always consult the official Palo Alto Networks documentation (Compatibility Matrix, Administrator's Guides) for the most up-to-date information for your PAN-OS version.

PCNSE/PCNSA Exam Note (Palo Alto Networks): For the PCNSE, you should be aware that PAN-OS supports HSM integration for protecting private keys used in decryption (especially Forward Trust CA key and Inbound Inspection server keys). Know the general benefits (enhanced security, compliance). You are not typically expected to know detailed HSM configuration steps, but understanding the *why* and *what* is important.

HSM Configuration Overview in PAN-OS:

The exact configuration steps vary depending on the HSM vendor and PAN-OS version, but generally involve:

1. HSM Setup:
   • Initialize and configure the HSM appliance itself (network settings, partitions/slots, user roles, client registration).
   • Install necessary client software or drivers on the Palo Alto Networks firewall if required by the HSM vendor (often done via a PAN-OS HSM client package).
2. Firewall HSM Configuration (Device > HSM):
   • Add an HSM configuration profile on the firewall.
   • Provide details such as HSM IP address(es), port, partition label/password, and client certificate/key for authentication to the HSM (if applicable).
   • Establish a secure connection between the firewall and the HSM.
3. Generating/Importing Keys on HSM:
   • For Forward Trust CA: You can generate the CA key pair directly on the HSM via the firewall interface, or import an existing CA key pair into the HSM (if supported by the HSM and PAN-OS). The private key remains on the HSM.
   • For SSL Inbound Inspection Server Keys: Generate server key pairs on the HSM, or import existing server private keys into the HSM.
4. Associating Certificates with HSM-Stored Keys:
   • When generating a certificate on the firewall (e.g., for Forward Trust CA) or importing a certificate (e.g., for an Inbound Inspection server cert whose key is on HSM), you specify that the private key resides on the configured HSM.
   • PAN-OS will then instruct the HSM to perform cryptographic operations (like signing or decryption) using the key stored within the HSM, rather than using a key stored on the firewall's local filesystem.
5. Decryption Profile Configuration:
   • In the Decryption Profile (Objects > Decryption > Decryption Profile), you may need to explicitly enable HSM usage or select keys that are HSM-protected. For example, there might be options like "Use HSM for Forward Trust private key operations."
   • Specify actions if HSM is not available (e.g., "Block sessions if HSM not available").

High-level interaction between a Palo Alto Networks firewall and an HSM. Private keys are stored on the HSM, and the firewall requests cryptographic operations from the HSM, enhancing key security.

Considerations for HSM Integration:

• Performance: Performing cryptographic operations on an external HSM introduces network latency compared to using locally stored keys. The performance impact depends on the HSM model, network speed between firewall and HSM, and the volume of operations. High-performance HSMs are designed to minimize this. Test thoroughly.
• Complexity: HSM integration adds complexity to the setup and management of the decryption infrastructure.
• Cost: HSMs are specialized hardware and represent an additional investment.
• High Availability (HA) for HSMs: Ensure your HSM deployment is also highly available (e.g., clustered HSMs) to prevent it from becoming a single point of failure for decryption services. The firewall should be configured to connect to multiple HSMs in an HA group if available.
• Backup and Recovery: Securely back up HSM key material according to vendor best practices.
• PAN-OS Version Compatibility: Always verify HSM vendor, model, and firmware compatibility with your specific PAN-OS version.

Gotcha! (Palo Alto Networks): Misconfiguring the HSM settings on the firewall, network connectivity issues between the firewall and HSM, or HSM partition/client authentication problems can lead to decryption failures. If the Decryption Profile is set to "Block sessions if HSM not available," an HSM issue can halt all traffic requiring HSM-based decryption. Careful planning and testing are essential.

Back Next

PCNSE Knowledge Check: Palo Alto Networks Decryption