TLS 1.3 Decryption on Palo Alto Networks Platforms

Introduction: TLS 1.3 Benefits and Decryption Support

TLS 1.3 represents a significant advancement over previous TLS versions, designed primarily to enhance security and performance for encrypted communications. Key improvements include a faster handshake process, mandatory Perfect Forward Secrecy (PFS), and the removal of older, less secure cryptographic algorithms.

Palo Alto Networks Next-Generation Firewalls (NGFWs) and Prisma Access support TLS 1.3 decryption for SSL Forward Proxy (outbound), SSL Inbound Inspection , decrypted Network Packet Broker traffic, and Decryption Port Mirroring . This capability is crucial for maintaining visibility into encrypted traffic, allowing security services like Threat Prevention, Advanced URL Filtering, WildFire, and DNS Security to inspect traffic and prevent threats hidden within TLS 1.3 sessions.

Without decryption, the security enhancements of TLS 1.3 could inadvertently create blind spots for security inspection.

Supported TLS 1.3 Cipher Suites for Decryption:

• TLS13-AES-128-GCM-SHA256
• TLS13-AES-256-GCM-SHA384
• TLS13-CHACHA20-POLY1305-SHA256

Key Differences: TLS 1.3 vs. TLS 1.2

• Handshake Speed: TLS 1.3 typically requires only one round trip (1-RTT) for a full handshake after the initial connection, compared to two round trips (2-RTT) for TLS 1.2. This significantly reduces latency, especially for connections over high-latency networks. TLS 1.3 also supports a zero round trip (0-RTT) mode for session resumption under certain conditions, further improving performance.
• Perfect Forward Secrecy (PFS): TLS 1.3 mandates PFS by exclusively using ephemeral key exchange algorithms like Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). This means compromising a server's long-term private key won't allow decryption of past sessions. TLS 1.2 supported PFS but also allowed static RSA key exchange, which does not provide forward secrecy.
• Cipher Suite Simplification: TLS 1.3 removes support for older, weaker algorithms (like RC4, 3DES, MD5, SHA1) and static RSA key exchange. It uses modern Authenticated Encryption with Associated Data (AEAD) ciphers (like AES-GCM and ChaCha20-Poly1305).
• Certificate Encryption: In TLS 1.3, the server's certificate message is encrypted after the initial ClientHello/ServerHello exchange. In TLS 1.2, it was sent in cleartext. This enhances privacy but creates challenges for decryption proxies (discussed below).

Simplified Handshake Comparison (Conceptual)

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: TLS 1.2 Handshake (Simplified 2-RTT)
    C->>S: ClientHello (TLS 1.2, Ciphers)
    S-->>C: ServerHello (TLS 1.2, Chosen Cipher)
    S-->>C: Certificate
    S-->>C: ServerKeyExchange (if DHE/ECDHE)
    S-->>C: ServerHelloDone
    C->>S: ClientKeyExchange
    C->>S: ChangeCipherSpec
    C->>S: Finished (Encrypted)
    S-->>C: ChangeCipherSpec
    S-->>C: Finished (Encrypted)
    C->>S: Application Data (Encrypted)

    Note over C,S: TLS 1.3 Handshake (Simplified 1-RTT)
    C->>S: ClientHello (TLS 1.3, Ciphers, KeyShare)
    S-->>C: ServerHello (TLS 1.3, Chosen Cipher, KeyShare)
    S-->>C: EncryptedExtensions
    S-->>C: Certificate (Encrypted)
    S-->>C: CertificateVerify (Encrypted)
    S-->>C: Finished (Encrypted)
    C->>S: Finished (Encrypted)
    C->>S: Application Data (Encrypted)
            

Performance Considerations: Overhead vs. Efficiency

While the native TLS 1.3 handshake is faster than TLS 1.2 due to fewer round trips, performing decryption on the firewall still introduces processing overhead.

• Decryption Overhead: The act of decrypting, inspecting, and re-encrypting traffic consumes CPU resources on the firewall's dataplane. This impact depends on the firewall model's capacity, the volume of traffic being decrypted, the session rate, and the specific cryptographic algorithms used.
• Algorithm Intensity:
  • Key Exchange: TLS 1.3 mandates ECDHE, which is generally considered more efficient than traditional DHE but still computationally intensive compared to static RSA (which TLS 1.3 doesn't use for key exchange). When comparing decryption across *different* TLS versions, decrypting a TLS 1.2 session using RSA key exchange might be less CPU-intensive *for the key exchange part* than decrypting a TLS 1.2 or 1.3 session using ECDHE/DHE on some hardware. However, modern hardware often has optimizations for ECC (Elliptic Curve Cryptography) used in ECDHE.
  • Symmetric Encryption/Authentication: TLS 1.3 uses modern AEAD ciphers like AES-GCM and ChaCha20-Poly1305. AES-GCM, especially with hardware acceleration (AES-NI instructions available on most modern CPUs and Palo Alto Networks hardware), is highly efficient.
  • Overall Impact: Factors like session setup rate, bulk encryption throughput, and specific hardware capabilities contribute significantly. High session rates with intensive key exchanges (like ECDHE/DHE) tend to be more CPU-bound than bulk data transfer using efficient ciphers like AES-GCM.
• Resource Consumption Factors (Recap from Q190): Key resource drivers during decryption include:
  • Key Exchange Algorithm (ECDHE/DHE vs. older RSA in TLS 1.2)
  • TLS Protocol Version (Affects handshake and available ciphers)
  • Transaction Size (More data = more symmetric encryption work)
  • Session Rate (Higher rate = more key exchanges)

Proper firewall sizing is crucial when planning a large-scale decryption deployment, especially considering the potential load increase from decrypting TLS 1.3 traffic. Refer to Palo Alto Networks sizing guides and performance datasheets.

TLS 1.3 Decryption Challenges & Considerations

The primary challenge introduced by TLS 1.3 for decryption proxies stems from the encryption of the server certificate during the handshake.

• Certificate Visibility Limitation: Because the server certificate is encrypted in TLS 1.3, the firewall cannot inspect its attributes (like CN, SAN, Issuer) early in the connection *without* performing decryption. This impacts:
  • Automatic Exclusions Based on Certificate Attributes: Firewalls cannot automatically add sites to the local exclusion cache based on certificate properties (e.g., self-signed, specific CNs) for TLS 1.3 sessions as they could with TLS 1.2.
  • "No Decrypt" Profile Checks: The checks within a "No Decryption" profile (Block Expired Certificates, Block Untrusted Issuers) are ineffective for TLS 1.3 traffic because the firewall cannot see the certificate details. These checks still function for TLS 1.2 and earlier traffic matching a "No Decrypt" rule.
  • Troubleshooting: Identifying certificate-related issues for TLS 1.3 connections often requires attempting decryption first or relying on client-side error messages.
• Mobile Applications and Certificate Pinning: Applications using certificate pinning are more likely to break under TLS 1.3 decryption if the firewall attempts to intercept, as the encrypted certificate prevents some workarounds that might have existed in TLS 1.2. Explicitly excluding pinned application traffic (via policy or global exclusion list) becomes more critical. Setting the Max Version to TLS 1.2 in the decryption profile for rules covering these apps is a common workaround.
• Middlebox Compatibility: While less common now, some older network devices might not correctly handle TLS 1.3 traffic, potentially causing connection issues even independent of decryption.

As stated in the original text, PAN-OS defaults to TLS 1.2 as the maximum if TLS 1.3 is not explicitly enabled in the profile. If a site doesn't support TLS 1.3, the firewall (when acting as a proxy) will negotiate down to a mutually supported version like TLS 1.2.

Configuration Best Practices for TLS 1.3 Decryption

Based on Palo Alto Networks recommendations and the characteristics of TLS 1.3:

• Decryption Profile - Protocol Versions:
  • Set Max Version to Max to automatically adopt TLS 1.3 and future versions.
  • Set Min Version generally to TLSv1.2 for broad compatibility while blocking older, insecure protocols (SSLv3, TLSv1.0, TLSv1.1). Only set Min to TLSv1.3 if you are certain all required destinations support it, or for specific policy rules targeting only TLS 1.3 services.
  • For traffic involving mobile apps known to use certificate pinning, consider creating a separate Decryption Policy Rule matching that traffic and apply a Decryption Profile with Max Version set to TLSv1.2 , or exclude the traffic via the global exclusion list.
• Algorithm Selection: Stick with default supported algorithms for TLS 1.3 (AES-GCM, ChaCha20). For TLS 1.2 compatibility (when Min Version allows it), ensure strong algorithms like AES-GCM and ECDHE are enabled, and disable weak ones (3DES, RC4, MD5, SHA1) unless absolutely required for specific legacy compatibility (using a dedicated profile/policy rule).
• Exclusions:
  • Use the global Decryption Exclusion List (Device > Setup > Session) for sites that break decryption for *technical* reasons (pinning, unsupported modes not handled by profile blocks).
  • Use Decryption Policy Rules with a "No Decrypt" action for traffic excluded for *policy* reasons (privacy, legal - e.g., Financial, Healthcare URL categories). Attach a "No Decryption" profile to these rules for basic certificate checks on TLS 1.2/earlier traffic.
• Logging: Enable logging for both successful and unsuccessful handshakes in relevant Decryption Policy rules for maximum visibility, ensuring adequate log storage quota is allocated. Remember that certificate checks in "No Decrypt" profiles don't apply to TLS 1.3.
• Phased Rollout (Recap from Q274): When starting decryption, adopt a phased approach. Begin by decrypting high-risk categories or specific applications/users, monitor performance and compatibility, and gradually expand the scope rather than attempting to decrypt everything at once.