Palo Alto Networks Deep Dive: Mastering SSL/TLS Decryption

Introduction to SSL/TLS Decryption on Palo Alto Networks NGFWs

In today's threat landscape, a significant portion of internet traffic is encrypted using SSL/TLS. While encryption is crucial for privacy and data integrity, it also creates a blind spot for security devices. Malicious actors leverage SSL/TLS to conceal malware, command-and-control (C2) communications, and data exfiltration. Palo Alto Networks Next-Generation Firewalls (NGFWs) provide robust SSL/TLS decryption capabilities to regain visibility into encrypted traffic, enabling comprehensive threat prevention.

The core philosophy behind Palo Alto Networks' decryption strategy is "Decrypt for Visibility and Control." By decrypting traffic, the firewall can apply its full suite of security services, including App-ID™, Content-ID™ (Threat Prevention, WildFire®, URL Filtering), and User-ID™, to previously opaque data streams.

Types of Decryption Supported by PAN-OS

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

• SSL Forward Proxy: Decrypts outbound SSL/TLS traffic initiated by internal users accessing external websites or services. The firewall acts as a "man-in-the-middle" (MITM), establishing separate SSL sessions with the client and the server. This is the most common decryption deployment.
• SSL Inbound Inspection: Decrypts inbound SSL/TLS traffic destined for internal servers (e.g., web servers, application servers). This allows the firewall to inspect traffic for threats before it reaches critical internal resources. The firewall needs access to the server's certificate and private key.
• SSH Proxy: Decrypts SSHv2 traffic, providing visibility into SSH sessions, including commands executed and files transferred. This helps prevent unauthorized access, data exfiltration, and malicious activity over SSH.
• SSL Forward Proxy with TLSv1.3 Decryption without Server Certificate: (Available in later PAN-OS versions) For TLSv1.3 sessions, PAN-OS can perform decryption for visibility without requiring the server's private key, provided certain conditions and cipher suites are met. However, for full inspection and modification capabilities, the traditional forward proxy model is more comprehensive.

Overview of Palo Alto Networks decryption types: SSL Forward Proxy for outbound traffic, SSL Inbound Inspection for inbound traffic to internal servers, and SSH Proxy for SSH sessions. Each allows the NGFW to apply security services.

Decryption Algorithms and PAN-OS

Palo Alto Networks NGFWs leverage various cryptographic algorithms during the decryption and re-encryption process. Understanding these is key to configuring secure and performant decryption policies.

Key Exchange Algorithms

Key exchange algorithms are used to securely establish a shared secret key between two parties. PAN-OS supports:

• RSA: A traditional asymmetric key exchange method. While widely supported, it does not provide Perfect Forward Secrecy (PFS). If the server's private key is compromised, past RSA sessions can be decrypted. Palo Alto Networks firewalls can decrypt RSA-based key exchanges when acting as a forward proxy or for inbound inspection if the server's private key is available.
• DHE (Diffie-Hellman Ephemeral): Provides PFS because a unique, temporary (ephemeral) key is generated for each session. Even if a long-term private key is compromised, past DHE sessions remain secure. DHE can be resource-intensive.
• ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): Offers PFS like DHE but with smaller key sizes and better performance due to the efficiency of elliptic curve cryptography. ECDHE is the preferred key exchange mechanism in modern TLS and is widely supported by PAN-OS for decryption.

Encryption Algorithms (Symmetric Ciphers)

Once a shared secret is established via key exchange, symmetric encryption algorithms are used for bulk data encryption. PAN-OS supports modern, strong ciphers:

• AES-128-GCM (Advanced Encryption Standard with Galois/Counter Mode): An Authenticated Encryption with Associated Data (AEAD) cipher. It provides both confidentiality and integrity. AES-128-GCM offers a good balance of security and performance.
• AES-256-GCM: Similar to AES-128-GCM but uses a 256-bit key, offering stronger encryption. This may have a slightly higher performance impact on the firewall's data plane processors.
• CHACHA20-POLY1305: Another AEAD cipher that is performant, especially on platforms without dedicated AES hardware acceleration. It is commonly used in mobile and software-based TLS implementations.

PAN-OS allows administrators to specify preferred cipher suites and algorithm versions in Decryption Profiles, enabling fine-grained control over the cryptographic parameters used in decrypted sessions.

Authentication Algorithms (Hashing)

Hashing algorithms are used for message integrity verification and in digital signatures.

• SHA-256 (Secure Hash Algorithm 256-bit): Commonly used in TLS 1.2 and TLS 1.3 for verifying the integrity of handshake messages and in certificate signatures.
• SHA-384 (Secure Hash Algorithm 384-bit): Offers stronger integrity protection than SHA-256 and is often paired with stronger encryption algorithms like AES-256.

Resource Utilization Impact of Decryption on Palo Alto Networks Firewalls

Decrypting SSL/TLS traffic is a computationally intensive process that consumes CPU and memory resources on the Palo Alto Networks firewall. The impact varies based on several factors specific to the PAN-OS environment:

• Volume of Encrypted Traffic: The most direct factor. More traffic to decrypt means higher resource utilization, particularly on the Data Plane CPUs.
• Key Exchange Method:
  • RSA: Generally less CPU-intensive for the firewall during the key exchange phase if it already possesses the server's private key (for inbound inspection) or if it's performing a simpler MITM for SSL Forward Proxy.
  • DHE/ECDHE: More CPU-intensive for the firewall because it must perform computationally expensive operations to generate ephemeral keys for *both* the client-side and server-side SSL sessions it establishes. ECDHE is typically more efficient than DHE.
• Encryption Algorithm and Key Size: Stronger algorithms and larger key sizes (e.g., AES-256-GCM vs. AES-128-GCM) require more processing power for encryption and decryption operations.
• TLS Version:
  • TLS 1.2: Involves more round trips in the handshake compared to TLS 1.3.
  • TLS 1.3: Features a streamlined handshake (1-RTT or even 0-RTT for session resumption). While this improves latency, the encryption starts earlier in the handshake, and certain elements like server certificates are encrypted. This can shift the computational load. Palo Alto Networks firewalls are optimized to handle TLS 1.3 decryption efficiently.
• Firewall Platform and Hardware Acceleration:
  • Palo Alto Networks PA-Series firewalls vary in their decryption capabilities. Higher-end models (e.g., PA-5400 Series, PA-7000 Series) have dedicated hardware resources (specialized crypto processors or FPGAs) to offload cryptographic operations, significantly boosting decryption throughput and reducing the load on general-purpose data plane CPUs.
  • Mid-range and branch office firewalls (e.g., PA-400 Series, PA-800 Series) also have cryptographic acceleration, but their overall capacity will be lower.
• Session Rate vs. Throughput: A high rate of new SSL/TLS sessions being established (high connections per second) can heavily load the CPU due to repeated key exchange computations. High throughput on already established sessions primarily loads the symmetric encryption/decryption processing.

It's essential to size your Palo Alto Networks firewall appropriately based on the expected decryption load. Consult the official Palo Alto Networks PA-Series performance and capacity datasheets , which provide specific metrics for "SSL Decryption Throughput (CPS)" and "SSL Decryption Concurrent Sessions." Always consider real-world traffic patterns, as datasheet numbers are often based on ideal conditions.

To monitor resource utilization in PAN-OS:

• GUI: Dashboard > System Resources; ACC > Decryption Tab.
• CLI:

  > show running resource-monitor ingress-backlogs (Check for crypto backlogs)
  > show session info (Look for active decrypted sessions)
  > show counter global filter aspect SSlproxy (Detailed SSL proxy counters)
  > show system resources (General CPU/memory usage)
              

TLS 1.3 Caveats and Considerations in PAN-OS

TLS 1.3, the latest version of the TLS protocol, introduces significant security and performance improvements. However, these changes also present specific considerations for decryption on Palo Alto Networks firewalls:

• Encrypted Server Name Indication (SNI) - ESNI/ECH:
  • Traditionally, SNI (which indicates the hostname the client is trying to reach) is sent in cleartext during the Client Hello. This allows PAN-OS to perform URL filtering and apply policies based on hostname even without full decryption.
  • TLS 1.3 introduces the possibility of Encrypted SNI (ESNI), now evolved into Encrypted Client Hello (ECH). If ECH is used, the SNI is encrypted.
  • PAN-OS Impact: If traffic uses ECH and is not decrypted by a Decryption policy, the firewall cannot see the SNI. This means:
    • URL Filtering based on hostname may not work for that session.
    • App-ID might only identify the application as "ssl" or "tls1.3" rather than the specific web application.
  • Palo Alto Networks Recommendation: To maintain visibility and control, decrypt traffic that might use ECH. PAN-OS can decrypt TLS 1.3 sessions, including those potentially using ECH, if a matching decryption policy is in place.
• Certificate Information Encryption:
  • In TLS 1.3, the server's certificate message is encrypted after the initial handshake.
  • PAN-OS Impact: Without decryption, the firewall cannot inspect the server's certificate details (e.g., issuer, subject, validity) directly from the encrypted handshake. This limits its ability to block sessions based on untrusted or revoked server certificates for non-decrypted traffic.
  • When PAN-OS decrypts TLS 1.3 (e.g., via SSL Forward Proxy), it terminates the TLS session from the server and establishes a new one with the client, allowing full inspection of the original server certificate.
• Reduced Handshake Round Trips:
  • TLS 1.3 significantly reduces the number of round trips required for the handshake (typically 1-RTT, down from 2-RTT in TLS 1.2). This improves connection establishment latency.
  • PAN-OS Impact: This generally benefits performance. Palo Alto Networks firewalls are designed to handle the faster handshake of TLS 1.3 efficiently. The decryption engine processes the streamlined flow, but the cryptographic operations themselves (key exchange, bulk encryption) still require processing.
• Mandatory Perfect Forward Secrecy (PFS):
  • TLS 1.3 mandates the use of key exchange mechanisms that provide PFS (like ECDHE). Static RSA key exchange is no longer allowed for establishing the main session keys.
  • PAN-OS Impact: This aligns with security best practices. Palo Alto Networks firewalls fully support PFS-enabled cipher suites and must actively participate in the ephemeral key exchange when decrypting TLS 1.3 traffic in a forward proxy scenario.
• Compatibility Issues with Decryption:
  • While rare, some applications or servers might have strict TLS 1.3 implementations or use features (like custom extensions) that could be sensitive to MITM decryption. This can sometimes lead to broken applications.
  • Palo Alto Networks Recommendation: Implement robust Decryption Exclusions (no-decrypt policies) for known problematic applications, domains, or URL categories. Use Palo Alto Networks' predefined lists or create custom ones. Thorough testing during a phased rollout is crucial. Common areas for exclusion include financial services, healthcare portals, and services using certificate pinning where the application expects a specific server certificate.
• Performance Considerations:
  • While the TLS 1.3 handshake is faster, the actual cryptographic load for decryption depends on the chosen ciphers and traffic volume. The benefits of a faster handshake are more noticeable for latency-sensitive applications.
  • PAN-OS hardware and software are optimized for TLS 1.3 decryption. Ensure your firewall platform is adequately sized for the anticipated TLS 1.3 decryption load.

Ensure that your Decryption Profiles in PAN-OS are configured to support TLS 1.3 (e.g., by setting appropriate minimum/maximum TLS versions and supported cipher suites). Palo Alto Networks regularly updates PAN-OS to enhance TLS 1.3 support and address emerging standards.

Configuring Decryption in PAN-OS

Setting up SSL/TLS decryption on a Palo Alto Networks firewall involves several key components and steps. A methodical approach is recommended.

1. Certificate Management (Prerequisites)

Certificates are fundamental to SSL/TLS decryption. PAN-OS needs specific certificates depending on the decryption type:

• Forward Trust Certificate (for SSL Forward Proxy):
  • This is a CA certificate that the firewall uses to re-sign server certificates it presents to clients during SSL Forward Proxy.
  • Clients must trust this CA certificate. Typically, this involves importing it into the trusted root CA store of client browsers and operating systems.
  • You can generate a self-signed CA on the firewall or import a CA certificate from an internal enterprise PKI (e.g., Microsoft CA). Using an enterprise PKI subordinate CA is often preferred for easier management in corporate environments.
  • GUI Path: Device > Certificate Management > Certificates > Generate (for self-signed) or Import . Mark this certificate as "Forward Trust."
• Forward Untrust Certificate (for SSL Forward Proxy):
  • This certificate is presented to clients when they attempt to connect to a site whose original server certificate is untrusted (e.g., expired, self-signed, wrong hostname, revoked).
  • This results in a clear browser warning, alerting the user to the issue, rather than silently dropping the connection or allowing a potentially insecure connection.
  • GUI Path: Device > Certificate Management > Certificates > Generate (typically a self-signed certificate clearly indicating an untrusted site). Mark this certificate as "Forward Untrust."
• Server Certificates (for SSL Inbound Inspection):
  • To decrypt traffic to your internal servers, the firewall needs the server's actual certificate and its corresponding private key.
  • These are imported onto the firewall. The private key must be exportable from the server.
  • GUI Path: Device > Certificate Management > Certificates > Import . Ensure you import both the certificate and the private key.
• Trusted Root CAs:
  • PAN-OS maintains a list of well-known public CA certificates that it trusts by default. This list is updated with PAN-OS software and content updates.
  • You can add your enterprise root CAs to this list if needed.
  • GUI Path: Device > Certificate Management > Certificates (default trusted CAs are pre-loaded).

Palo Alto Networks Certificate Management for Decryption: Clients must trust the Forward Trust CA. The firewall uses this CA for SSL Forward Proxy and an Untrust CA for sites with certificate issues. For Inbound Inspection, the server's actual certificate and private key are needed on the firewall.

2. Decryption Profiles

Decryption Profiles control the parameters and checks performed during decryption for SSL/TLS and SSH traffic. You can create multiple profiles for different needs.

• SSL Protocol Settings:
  • Specify minimum and maximum TLS/SSL versions (e.g., allow TLS 1.2 and TLS 1.3, block older SSLv3).
  • Configure supported key exchange algorithms, encryption algorithms, and authentication algorithms (cipher suites). You can choose predefined "recommended" sets or customize them.
• Server Certificate Verification Options (for SSL Forward Proxy):
  • Block sessions with expired certificates: Enforces validity period.
  • Block sessions with untrusted issuers: Checks if the server's CA is in the firewall's trusted CA list.
  • Block sessions with unknown certificate status: If OCSP/CRL checks fail to determine revocation status.
  • And other checks like hostname mismatch, certificate extensions etc.
• Unsupported Modes: Define actions for unsupported cipher suites or protocol versions (e.g., no decrypt, block session).
• No Decryption Options: Define actions if decryption fails for other reasons (e.g., client authentication required, resource constraints).
• SSH Proxy Settings: Enable/disable SSH Proxy features like blocking sessions with unsupported algorithms.

GUI Path: Objects > Decryption > Decryption Profile

3. Decryption Policies

Decryption Policies determine *what* traffic to decrypt. They function similarly to Security Policies, using match criteria and actions.

• Matching Criteria:
  • Source/Destination Zones
  • Source/Destination Addresses (or Address Groups)
  • User-ID (users or groups)
  • Service (e.g., `ssl`, `https`, `ssh`, or custom port-based services)
  • URL Category (requires a URL Filtering license and profile)
  • Application (less common for initial decryption policy, as App-ID on SSL might just be "ssl" before decryption)
• Actions:
  • Decrypt: This is the action to perform SSL Forward Proxy, SSL Inbound Inspection, or SSH Proxy. You must select a Decryption Profile to apply.
    • For SSL Inbound Inspection, you also specify the server certificate (and key) that the firewall should use for that particular server/service.
  • No Decrypt: Explicitly bypasses decryption for matching traffic. This is crucial for creating exclusions.
  • Block (SSH only): Can block SSH sessions.

Decryption policies are evaluated top-down. The first match determines the action.

GUI Path: Policies > Decryption

Palo Alto Networks Decryption Policy evaluation flow. Policies are checked top-down. "No Decrypt" rules are essential for exclusions. Matching "Decrypt" rules apply a specified Decryption Profile.

4. Hardware Security Module (HSM) Integration (Advanced)

For environments requiring the highest level of security for private keys (especially for SSL Inbound Inspection or the Forward Trust CA private key), Palo Alto Networks firewalls can integrate with certified third-party Hardware Security Modules (HSMs).

• The HSM securely stores and manages cryptographic keys.
• The firewall communicates with the HSM to perform cryptographic operations involving these keys, so the private keys never leave the HSM.
• This adds complexity and cost but provides enhanced key protection.
• Configuration involves setting up the HSM, network connectivity, and configuring the firewall to use the HSM for specific certificates. Refer to Palo Alto Networks documentation for supported HSM vendors and configuration guides.

GUI Path: Device > HSM

Palo Alto Networks Decryption Best Practices

Implementing decryption effectively requires careful planning and adherence to best practices to maximize security benefits while minimizing operational impact.

• Phased Deployment:
  • Start with a pilot group of users or non-critical applications.
  • Monitor resource utilization, application compatibility, and user experience.
  • Gradually expand decryption to more users, zones, or URL categories. This allows for identifying and resolving issues (like applications needing exclusion) in a controlled manner.
• Communicate with Users:
  • Inform users about the decryption initiative, its purpose (security), and any steps they need to take (e.g., if they encounter certificate warnings before the Forward Trust CA is fully distributed).
  • Provide a clear point of contact for reporting issues.
• Robust Certificate Management:
  • Use an Enterprise CA (subordinate CA) for the Forward Trust certificate if possible, for easier deployment via Group Policy or MDM solutions.
  • Regularly monitor the expiration dates of all certificates used in decryption (Forward Trust, Forward Untrust, Inbound Server Certificates). PAN-OS can generate alerts for expiring certificates.
• Strategic Decryption Exclusions ("No-Decrypt" Policies):
  • Create explicit "No Decrypt" policies for categories of traffic that should not be decrypted. Place these policies *before* general "Decrypt" policies. Common exclusions include:
    • Financial Services: Due to sensitivity and potential for breaking banking sites.
    • Healthcare: Due to privacy regulations (HIPAA, GDPR) and application sensitivity.
    • Applications with Certificate Pinning: Where the application expects a specific server certificate and will fail if it sees the firewall's re-signed certificate.
    • Streaming Media (Optional): High-volume, low-risk streaming traffic can consume significant decryption resources. Consider excluding if resources are constrained and risk is acceptable.
    • Problematic Sites/Applications: Maintain a list of specific FQDNs or applications discovered during testing that require exclusion.
  • Palo Alto Networks provides predefined lists of applications known to break with decryption that can be used in exclusion policies. ( Objects > Applications , search for `ssl-no-inspect` tag or similar application filters).
  • Regularly review and update exclusion lists.
• Leverage URL Categories for Decryption Policies:
  • Applying decryption based on URL Categories (e.g., "social-networking," "high-risk," "unknown-sites") can be more scalable than managing lists of FQDNs. Requires a URL Filtering license.
  • For example, you might choose to decrypt all categories except finance and healthcare.
• Monitor Firewall Resources:
  • Continuously monitor CPU (especially Data Plane), memory, and session capacity after enabling decryption.
  • Use `show running resource-monitor` CLI command to check for resource contention.
  • Adjust decryption scope if the firewall is becoming overloaded.
• Logging and Auditing:
  • Enable detailed logging for decryption events (Decryption Log). This helps in troubleshooting and understanding what traffic is being decrypted or skipped.
  • Review logs regularly for errors (e.g., certificate validation failures, handshake errors).
• Keep PAN-OS and Content Updates Current:
  • Regularly update PAN-OS software and Applications & Threats content. These updates include improvements to decryption handling, support for new ciphers, and updated lists of applications/sites.
• Understand "Block sessions with unsupported versions/ciphers":
  • In Decryption Profiles, carefully consider the implications of blocking traffic that uses older TLS versions or weak ciphers. While good for security, it might break access to legacy systems if they cannot be updated. Balance security with operational needs.

Impact of Decryption on Palo Alto Networks Security Services

Enabling SSL/TLS decryption is a game-changer for the effectiveness of Palo Alto Networks' core security services, transforming them from partially blind to fully seeing.

Comparison of Palo Alto Networks security service effectiveness with and without SSL/TLS decryption. Decryption unlocks deep inspection capabilities.

• App-ID™ (Application Identification):
  • Without Decryption: For SSL/TLS traffic, App-ID can typically only identify the application as "ssl" or "tls," or sometimes a generic web application based on SNI or IP address. It cannot see the true application running over the encrypted tunnel (e.g., Facebook-chat vs. Facebook-posting, or specific SaaS applications).
  • With Decryption: App-ID gains full visibility into the decrypted application data. It can accurately identify specific web applications (e.g., Salesforce, Office365, Gmail), sanctioned and unsanctioned SaaS applications, and even distinguish different functions within an application. This enables granular policy control. It can also identify applications attempting to tunnel over SSL/TLS, like P2P or TOR.
• Content-ID™ (Threat Prevention, WildFire®, URL Filtering, DNS Security):
  • Threat Prevention (Antivirus, Anti-Spyware, Vulnerability Protection):
    • Without Decryption: Signatures for viruses, spyware, and exploits cannot be matched against encrypted payloads. Threat Prevention is largely ineffective.
    • With Decryption: The firewall inspects the decrypted content for known and unknown threats using its full signature sets. This is critical for stopping malware downloads, C2 communications, and exploit attempts hidden in SSL/TLS.
  • WildFire® (Cloud-based Threat Analysis):
    • Without Decryption: Encrypted files cannot be submitted to WildFire for analysis. The firewall cannot identify zero-day malware within SSL/TLS.
    • With Decryption: The firewall can extract decrypted files (PE, PDF, Office documents, etc.) and send them to WildFire for dynamic analysis. This enables detection of previously unknown malware.
  • URL Filtering:
    • Without Decryption: URL filtering primarily relies on the SNI in the Client Hello (if not encrypted by ECH) or the server's IP address. It cannot see the full URL path or query parameters.
    • With Decryption: The firewall sees the full HTTP GET/POST requests within the decrypted stream, allowing for more granular URL filtering based on complete URLs and custom URL categories.
  • DNS Security:
    • While DNS Security primarily inspects DNS queries (which are typically UDP/TCP port 53 and not SSL encrypted themselves unless using DNS-over-HTTPS/TLS), decryption is crucial if malware uses HTTPS for C2 communication *after* a malicious DNS lookup. Decrypting the subsequent HTTPS C2 traffic allows Threat Prevention and WildFire to identify and block it.
• User-ID™ (User Identification):
  • User-ID itself (mapping IPs to users) is not directly dependent on decryption. However, the *effectiveness* of applying user-based policies to specific applications and threats within encrypted traffic relies heavily on decryption. Without it, you might allow a user access to "ssl" traffic, but not know if they are using a sanctioned app or exfiltrating data via an unauthorized encrypted channel.
• Data Filtering (Part of Content-ID):
  • Without Decryption: Data Filtering profiles cannot inspect encrypted payloads for sensitive data patterns (e.g., credit card numbers, social security numbers).
  • With Decryption: Data Filtering profiles can scan decrypted content to prevent data exfiltration of sensitive information over SSL/TLS.

Palo Alto Networks SSL Forward Proxy: A Deeper Look

SSL Forward Proxy is used to decrypt outbound SSL/TLS sessions initiated by clients on the protected network. The Palo Alto Networks firewall acts as a "man-in-the-middle" (MITM), intercepting and inspecting the traffic.

How SSL Forward Proxy Works:

1. Client Initiates Connection: An internal client attempts to connect to an external secure server (e.g., `https://www.example.com`).
2. Firewall Intercepts: The Palo Alto Networks firewall, configured with an SSL Forward Proxy decryption policy matching this traffic, intercepts the client's ClientHello message.
3. Firewall to Server Session: The firewall, acting as a client, forwards the ClientHello (or a modified one) to the actual external server.
4. Server Responds: The external server responds with its ServerHello, its SSL certificate, and other handshake messages.
5. Firewall Validates Server Certificate: The firewall validates the external server's certificate against its list of trusted CAs.
   • If the server's certificate is trusted and valid, the firewall proceeds.
   • If the server's certificate is untrusted (e.g., self-signed, expired, wrong host), the firewall can either block the session or present the "Forward Untrust" certificate to the client, depending on the Decryption Profile settings. This results in a browser warning on the client side.
6. Firewall Forges Server Certificate: Assuming the original server certificate is valid, the firewall generates a new SSL certificate on-the-fly, impersonating the external server's identity (e.g., common name `www.example.com`). This new certificate is signed by the firewall's "Forward Trust" CA certificate.
7. Firewall to Client Session: The firewall presents this forged, re-signed certificate to the internal client.
8. Client Validates Forged Certificate: The client's browser/OS validates the certificate presented by the firewall. If the client trusts the firewall's "Forward Trust" CA, this validation succeeds, and an SSL session is established between the client and the firewall.
9. Two SSL Sessions: The firewall now maintains two separate SSL sessions:
   • Session 1: Client <-> Firewall
   • Session 2: Firewall <-> External Server
10. Decryption and Inspection: The firewall decrypts traffic from the client, inspects it using App-ID, Content-ID (Threat Prevention, URL Filtering, WildFire), re-encrypts it, and sends it to the external server. The process is reversed for traffic from the server to the client.

Palo Alto Networks SSL Forward Proxy handshake and data flow. The NGFW establishes separate SSL sessions with the client and the server, enabling inspection of the traffic exchanged between them.

Key Requirements for SSL Forward Proxy:

• Forward Trust CA Certificate: Must be installed and trusted on all client devices whose traffic will be decrypted.
• Decryption Policy: With action "Decrypt" and an appropriate Decryption Profile.

Use Cases:

• Inspecting employee internet access for malware, C2, and policy violations.
• Enforcing acceptable use policies for web access.
• Preventing data exfiltration through encrypted channels.
• Gaining visibility into SaaS application usage.

Palo Alto Networks SSL Inbound Inspection: A Deeper Look

SSL Inbound Inspection is used to decrypt and inspect SSL/TLS traffic destined for internal servers (e.g., corporate web servers, application servers) that are protected by the Palo Alto Networks firewall. This allows the firewall to detect and block threats before they reach these critical assets.

How SSL Inbound Inspection Works:

1. External Client Initiates Connection: An external client attempts to connect to an internal secure server (e.g., `https://yourcompany.com`) whose traffic passes through the Palo Alto Networks firewall.
2. Firewall Intercepts: A Decryption policy configured for SSL Inbound Inspection matches this traffic.
3. SSL Handshake with Client: The firewall uses the imported legitimate SSL certificate and private key of the internal server to negotiate an SSL session directly with the external client. The client believes it's talking directly to the server.
4. Traffic Decryption and Inspection: Once the SSL session is established between the external client and the firewall, the firewall decrypts the incoming traffic.
5. Security Processing: The decrypted traffic is then inspected by App-ID, Content-ID (Threat Prevention, WildFire, etc.).
6. Traffic Forwarding (Clear Text or Re-Encrypted):
   • Option 1 (Less Common): The firewall can forward the decrypted (clear text) traffic to the internal server. This offloads SSL processing from the server but requires the internal network segment to be secure.
   • Option 2 (More Common & Secure): The firewall re-encrypts the traffic (establishing a new SSL session if needed, or using the existing one if the server handles SSL) and forwards it to the internal server. This maintains end-to-end encryption in a broader sense, with the firewall as a trusted intermediary. Typically, if the internal server is already configured for HTTPS, the firewall just forwards the decrypted application data over a new or existing TCP connection, and the server itself might also be listening on HTTPS. In simpler terms, the firewall decrypts, inspects, and then forwards the (now clear) application data to the internal server, which is itself listening for HTTPS. The firewall doesn't necessarily re-encrypt to the server, but rather handles the client-facing SSL. If the internal server *only* accepts HTTP, then the firewall is doing SSL offloading. More commonly, for pure inspection, the server still does its own SSL, and the FW is inspecting before it gets there. *Correction for clarity*: For true SSL Inbound Inspection where the goal is just to *inspect*, the firewall uses the server's key to decrypt traffic from the client. It inspects it. Then, it typically forwards the *original encrypted packets* (or re-encrypts if it modified anything or if the internal server only speaks HTTP, which is SSL offloading) to the internal server. However, the most straightforward model of inbound inspection using the server's private key is that the firewall terminates the client's SSL, inspects, and then can either forward clear text or establish a *new* SSL session to the internal server. For simplicity, we'll assume it decrypts, inspects, and then forwards the traffic (potentially clear if the server expects HTTP, or re-encrypted if the server expects HTTPS from the firewall). Palo Alto Networks documentation states: "For SSL Inbound Inspection, the firewall uses the private key and certificate of the server that is being protected to decrypt and inspect traffic." After inspection, "the firewall forwards the traffic (clear text) to the destination server." This is SSL offloading combined with inspection. If the server itself *also* does SSL, and you want the firewall to inspect and then have the server *also* do SSL, that's a more complex setup and often not what "Inbound Inspection" primarily refers to on its own. Inbound inspection primarily means the FW is the SSL endpoint from the client's perspective.
7. Response Path: Traffic from the internal server back to the client is also processed by the firewall, encrypted, and sent to the external client.

Palo Alto Networks SSL Inbound Inspection flow. The NGFW uses the internal server's certificate and private key to decrypt and inspect traffic from external clients before it reaches the server.

Key Requirements for SSL Inbound Inspection:

• Server Certificate and Private Key: The legitimate certificate and corresponding private key for each internal server whose traffic is to be inspected must be imported onto the firewall. The private key must be marked as exportable on the server.
• Decryption Policy: With action "Decrypt," specifying the server certificate and an appropriate Decryption Profile. The service in the policy should match the port the server is listening on (e.g., TCP/443).

Use Cases:

• Protecting public-facing web servers from web application attacks, malware uploads, and exploits.
• Inspecting encrypted traffic to internal application servers for threats.
• Applying granular security policies to traffic destined for critical internal resources.

Palo Alto Networks SSH Proxy (Decryption)

SSH (Secure Shell) is widely used for secure remote administration of servers and network devices. However, like SSL/TLS, its encrypted nature can hide malicious activity. Palo Alto Networks SSH Proxy allows for the decryption and inspection of SSHv2 traffic.

How SSH Proxy Works:

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

1. Client Initiates SSH Connection: A user attempts to SSH to a server.
2. Firewall Intercepts: A Decryption policy with SSH Proxy enabled intercepts the connection.
3. Two SSH Tunnels: The firewall establishes two separate SSH tunnels:
   • One between the client and the firewall.
   • Another between the firewall and the destination server.
4. Key Handling: The firewall negotiates SSH keys with both the client and the server. It effectively proxies the SSH handshake and subsequent data.
5. Decryption and Inspection: The firewall decrypts the SSH traffic flowing in both directions. This allows it to inspect:
   • Commands being executed (if command logging is enabled).
   • File transfers (SFTP or SCP over SSH).
   • Port forwarding or tunneling attempts within the SSH session.
6. Content-ID Application: Threat Prevention profiles can be applied to inspect the decrypted SSH payload for malicious commands, scripts, or file content (e.g., blocking transfer of certain file types or malware).

Key Configuration Elements:

• Decryption Profile: Under the "SSH Proxy" tab, enable "Block sessions if unsupported algorithm" or "Block sessions if decryption disabled" as per policy.
• Decryption Policy:
  • Set the service to `ssh` (or the custom port if SSH runs on a non-standard port).
  • Action: "Decrypt". Select the Decryption Profile configured for SSH Proxy.
• Security Policy: An accompanying Security Policy must allow the SSH traffic (application `ssh`). Threat Prevention profiles can be attached to this Security Policy to inspect the decrypted content.

Security Benefits:

• Visibility into SSH Commands: Log executed commands for auditing and incident response (requires specific configuration and may have performance implications).
• Control over File Transfers: Block or monitor file transfers over SFTP/SCP.
• Threat Prevention: Apply Antivirus and Vulnerability Protection signatures to the decrypted SSH stream.
• Prevent Unauthorized Tunneling: Detect and block attempts to tunnel other protocols (e.g., RDP, VNC) through SSH.

Palo Alto Networks Decryption Port Mirroring

Decryption Port Mirroring is a feature in PAN-OS that allows a copy of decrypted SSL/TLS traffic to be sent to a specified interface on the firewall. This interface can then be connected to a third-party security or monitoring tool (e.g., a Data Loss Prevention (DLP) system, an Intrusion Detection System (IDS), or a packet capture utility) for further analysis or archiving.

How It Works:

1. The firewall performs SSL/TLS decryption as usual (e.g., SSL Forward Proxy or SSL Inbound Inspection).
2. After decryption but before re-encryption (for SSL Forward Proxy) or before sending to the internal server (for SSL Inbound Inspection), the firewall sends a copy of the cleartext (decrypted) Layer 2 frames to a designated physical interface on the firewall.
3. This interface must be configured as a "Decrypt Mirror" type interface.
4. The external tool connected to this mirror interface receives the raw decrypted packets.

Configuration:

• Interface Configuration:
  • Navigate to Network > Interfaces > Ethernet .
  • Select an unused physical interface.
  • Set the "Interface Type" to Decrypt Mirror .
  • This interface does not participate in routing or have an IP address.
• Decryption Policy/Profile:
  • There isn't a specific setting in the Decryption Policy or Profile to *enable* mirroring. Mirroring is enabled globally for all decrypted traffic once a Decrypt Mirror interface is configured and active.
  • However, you can control *which* traffic gets decrypted (and thus mirrored) via Decryption Policies.

Use Cases:

• Out-of-Band DLP: Send decrypted traffic to a dedicated DLP appliance to inspect for sensitive data exfiltration without adding inline processing load to the DLP system.
• Advanced Threat Analysis: Feed decrypted traffic into specialized threat hunting platforms or network forensics tools.
• Compliance and Archiving: Capture and store decrypted communications for regulatory compliance or long-term analysis.

Decryption Port Mirroring provides valuable flexibility for integrating decrypted visibility from Palo Alto Networks firewalls with other specialized security tools in an organization's ecosystem.

Palo Alto Networks Supported Cipher Suites

Palo Alto Networks firewalls, through PAN-OS, support a wide range of SSL/TLS cipher suites to ensure compatibility with diverse clients and servers, while also allowing administrators to enforce strong cryptography. A cipher suite is a named combination of algorithms used to secure an SSL/TLS connection, typically including:

• Key Exchange Algorithm (e.g., ECDHE, RSA)
• Authentication Algorithm (e.g., RSA, ECDSA - for signing certificates)
• Bulk Encryption Algorithm (e.g., AES-GCM, CHACHA20-POLY1305)
• Message Authentication Code (MAC) Algorithm (e.g., SHA256, SHA384 - often integrated in AEAD ciphers like AES-GCM)

Managing Cipher Suites in PAN-OS:

Cipher suite preferences and restrictions are primarily managed within Decryption Profiles .

GUI Path: Objects > Decryption > Decryption Profile > [Select or Add Profile]

Within a Decryption Profile, under the "SSL Protocol Settings" (for SSL Forward Proxy and Inbound Inspection) or "SSH" tab (for SSH Proxy), you can configure:

• Min Version / Max Version (for SSL/TLS): Specify the allowed SSL/TLS protocol versions (e.g., TLS 1.2, TLS 1.3). Setting a minimum version helps phase out weaker, older protocols.
• Key Exchange Algorithms: Enable/disable specific algorithms like RSA, DHE, ECDHE.
• Encryption Algorithms: Enable/disable specific symmetric ciphers like AES-128-CBC, AES-256-GCM, CHACHA20-POLY1305, etc.
• Authentication Algorithms: Enable/disable hashing algorithms like SHA1, SHA256, SHA384 used in message authentication and digital signatures.

PAN-OS often provides "recommended" default settings that balance security and compatibility. However, for specific compliance or security requirements, you might need to customize these settings (e.g., disabling all CBC-mode ciphers or disallowing RSA key exchange).

Finding the List of Supported Ciphers:

The exact list of supported cipher suites can vary slightly between PAN-OS versions and even specific firewall hardware platforms due to differences in cryptographic hardware acceleration capabilities. The most authoritative source for this information is the official Palo Alto Networks documentation for your specific PAN-OS version:

• Search on the Palo Alto Networks TechDocs site ( docs.paloaltonetworks.com ) for "supported cipher suites" along with your PAN-OS version (e.g., "PAN-OS 10.2 supported cipher suites").
• This documentation typically provides detailed tables listing the cipher suite names (IANA standard names), the PAN-OS internal name, and the specific algorithms they comprise.

Example from documentation might look like (this is illustrative):

Illustrative table of supported cipher suites. Always refer to official Palo Alto Networks documentation for your PAN-OS version.

Troubleshooting Cipher Mismatches:

If clients or servers are unable to establish SSL/TLS sessions through the firewall after decryption is enabled, a cipher suite mismatch can be a cause. This occurs if the firewall's Decryption Profile does not offer any cipher suites that are mutually supported by both the client and the end server.

• Check the firewall's System logs and Decryption logs for handshake failures or errors related to ciphers.
• Use tools like `ssllabs.com/ssltest/` (for public servers) or OpenSSL commands (`openssl s_client -connect server:port`) to check the ciphers supported by the client and server directly, then compare with what's configured in the PAN-OS Decryption Profile.

# Example OpenSSL command to check server ciphers
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3
        

By carefully managing supported cipher suites, Palo Alto Networks firewalls can ensure strong encryption for decrypted traffic while maintaining necessary interoperability.

References (Conceptual - Check Official Palo Alto Networks Docs)

While this guide aims to be comprehensive, always refer to the latest official Palo Alto Networks documentation for the most up-to-date and detailed information specific to your PAN-OS version and hardware platform. Key resources include:

• Palo Alto Networks TechDocs ( docs.paloaltonetworks.com ) for your PAN-OS version (e.g., Administrator's Guide, Decryption concepts, CLI Reference).
• Palo Alto Networks Knowledge Base articles.
• Palo Alto Networks LIVEcommunity discussions.
• PA-Series Performance and Capacity Datasheets for sizing.
• PCNSE Study Guides and Blueprint.

This document is intended as a study aid and should be supplemented with official Palo Alto Networks materials.