7.2 SSL Inbound Inspection for Internal Web Servers

7.2 SSL Inbound Inspection for Internal Web Servers

Core Concept: SSL Inbound Inspection enables Palo Alto Networks Next-Generation Firewalls (NGFW) to decrypt and inspect incoming SSL/TLS traffic directed to internal protected servers (such as public web servers or DMZ application clusters). By importing the target server's official private key and certificate onto the firewall, the NGFW inspects inbound threats in cleartext without requiring any certificate modifications or agent software on external client devices.

Inbound Threat Landscape & Server Protection Architecture

Enterprise web servers hosted in corporate Data Centers or Demilitarized Zones (DMZ) are subject to continuous targeting from external entities across the Internet. Attack vectors hiding inside inbound HTTPS sessions include SQL Injection (SQLi), Cross-Site Scripting (XSS), Remote Code Execution (RCE) exploits, zero-day web vulnerability probes, and malicious file uploads.

When inbound web traffic is encrypted with SSL/TLS, perimeter firewalls operating without decryption capability cannot inspect the incoming HTTP payload. Attackers take advantage of this encryption blind spot to deliver web exploits directly to internal application servers.

+-----------------------------------------------------------------------------------+
|                        SSL INBOUND INSPECTION ARCHITECTURE                        |
|                                                                                   |
|  [External Client] ---> [PAN-OS NGFW] -------------------> [Internal Server]      |
|  (Public Internet)       | Holds Imported Server           (DMZ / Data Center)    |
|                          | Private Key & Cert                                     |
|                          |                                                        |
|                          |-> Decrypts Inbound Payload                             |
|                          |-> Executes SP3 Threat Inspection                       |
|                          |   * IPS (SQLi, XSS, RCE signatures)                    |
|                          |   * Antivirus & File Blocking                          |
|                          |   * WildFire Zero-Day Scanning                         |
|                          |-> Re-encrypts / Forwards Payload                       |
+-----------------------------------------------------------------------------------+

Unlike SSL Forward Proxy (which inspects outbound connections initiated by internal users), SSL Inbound Inspection protects internal servers from external clients. Because the enterprise owns and controls the internal web servers, the server's official SSL/TLS private key and certificate can be installed directly onto the Palo Alto Networks firewall.

---

Key Import, Certificate Mapping, and Secure Key Storage

Implementing SSL Inbound Inspection requires importing the protected server's cryptographic identity into PAN-OS and creating targeted Decryption Policies.

Certificate & Private Key Import Workflow

1. Obtaining the Key Pair: The administrator exports the server's certificate and matching private key from the internal web server or PKI management portal. Common export formats include PKCS#12 (.pfx / .p12) or standalone PEM-encoded certificate and RSA/ECDSA key files.
2. Importing into PAN-OS:
   • Navigate to Device > Certificate Management > Certificates and select Import.
   • Upload the certificate and private key file, supplying the passphrase if the private key is encrypted.
   • Designate a clear, descriptive Certificate Name matching the server domain (e.g., webserver-cert-2026).
3. Master Key Encryption: Once imported, the private key is stored within the firewall's internal key store. PAN-OS secures private keys at rest using the firewall's Master Key. To prevent unauthorized key extraction, the private key cannot be exported back out of the firewall interface in cleartext.

Decryption Policy Rule Configuration

To apply SSL Inbound Inspection to incoming traffic:

• Navigate to Policies > Decryption and create a new rule.
• Source Zone: External/Untrust zone (e.g., Internet).
• Destination Zone: DMZ or internal zone hosting the web server (e.g., DMZ-Zone).
• Destination Address: The public IP address (or NATed IP) of the internal web server.
• Service: service-https (TCP port 443) or custom application ports.
• Action: decrypt.
• Type: Select ssl-inbound-inspection.
• Target Certificate: Select the imported server certificate (webserver-cert-2026).

---

Cryptographic Mechanics: RSA, ECDSA, and Perfect Forward Secrecy (PFS)

The cryptographic protocol negotiated during the TLS handshake dictates how the Palo Alto Networks dataplane processes decrypted sessions.

RSA Static Key Exchange vs. Ephemeral Diffie-Hellman (PFS)

Historical SSL/TLS implementations utilized static RSA key exchange algorithms (such as TLS_RSA_WITH_AES_256_CBC_SHA). Under static RSA key exchange, the client encrypts the TLS Pre-Master Secret using the server's public key. Because the firewall possesses the matching server private key, the firewall could passively derive the symmetric session key and decrypt the payload without participating directly in the handshake.

Modern TLS security standards mandate Perfect Forward Secrecy (PFS) using Ephemeral Diffie-Hellman cipher suites:

• DHE (Diffie-Hellman Ephemeral)
• ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)

Under PFS ciphers, static private keys are never used to encrypt session keys. Instead, the client and server negotiate temporary, ephemeral keys for every individual session. Consequently, passive eavesdropping is cryptographically impossible—even with access to the server's private key.

PAN-OS Inbound Proxy Mechanics for PFS

To inspect inbound TLS traffic protected by DHE or ECDHE cipher suites, PAN-OS operates as an active TLS proxy:

1. Active Handshake Participation: The firewall intercepts the client's ClientHello, negotiates the ECDHE key exchange parameters using its imported server certificate, and completes the server key exchange with the external client.
2. Dual Session Management: The firewall establishes a front-end TLS session with the external client and a back-end TLS session with the internal web server.
3. Algorithm & Curve Support: PAN-OS supports both RSA (2048-bit, 4096-bit) and ECDSA (P-256, P-384, X25519) key types for SSL Inbound Inspection across TLS 1.2 and TLS 1.3 protocols.

---

Session Resumption, Session Tickets, and Handshake Optimization

To reduce CPU overhead associated with full asymmetric TLS handshakes, modern web applications rely heavily on TLS Session Resumption.

Session Resumption Mechanisms

• Session IDs (RFC 5246): The server issues a unique Session ID to the client during the initial handshake. On subsequent connections, the client sends this Session ID in its ClientHello. If the server finds the ID in its session cache, key exchange is skipped, and previous symmetric keys are resumed.
• Session Tickets (RFC 5077 / TLS 1.3 PSK): The server encrypts session state parameters into a Session Ticket using a secret Ticket Encryption Key (STEK) and sends it to the client. Upon reconnecting, the client presents the ticket to resume the session statelessly.

Firewall Session State Synchronization

When SSL Inbound Inspection is active, session resumption presents a potential inspection challenge: if a client resumes a session that the firewall did not originally terminate or track, the firewall lacks the symmetric session keys needed to decrypt subsequent packets.

To maintain inspection continuity across resumed sessions:

• PAN-OS tracks session IDs and session tickets negotiated across the firewall cluster.
• If a client presents an un-tracked or unrecognized session ticket, the firewall forces a full TLS handshake renegotiation, ensuring that symmetric keys are derived under the firewall's control and cleartext inspection remains uninterrupted.

---

SP3 Engine Decryption & Multi-Stage Security Profile Enforcement

Decryption is not an end in itself; it is the enabler for full-stack threat prevention. Once inbound traffic is decrypted by the SSL Inbound Inspection engine, the cleartext payload is injected into the Single-Pass Parallel Processing (SP3) architecture.

+-----------------------------------------------------------------------------------+
|                        SP3 DECRYPTED DEEP PACKET INSPECTION                       |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [Decrypted HTTP Payload]                                                         |
|         |                                                                         |
|         +---> 1. App-ID Engine                                                    |
|         |        * Elevates generic 'ssl' to 'web-browsing' or specific app       |
|         |        * Identifies underlying HTTP methods (GET, POST, PUT, DELETE)    |
|         |                                                                         |
|         +---> 2. Threat Prevention Engine (IPS)                                   |
|         |        * Scans for SQL Injection (SQLi) patterns                        |
|         |        * Detects Cross-Site Scripting (XSS) and RCE attacks             |
|         |        * Matches CVE vulnerability signatures against web servers       |
|         |                                                                         |
|         +---> 3. Antivirus & WildFire Engine                                      |
|         |        * Scans uploaded files for malicious code                        |
|         |        * Forwards unknown executable payloads to WildFire cloud          |
|         |                                                                         |
|         +---> 4. Data Filtering & File Blocking                                   |
|                  * Prevents credit card / SSN exfiltration from database queries  |
|                  * Enforces upload file-type restriction policies                 |
+-----------------------------------------------------------------------------------+

Multi-Stage Security Pipeline

1. App-ID Re-identification: Prior to decryption, the session is classified broadly as ssl (TCP port 443). Once decrypted, the App-ID engine inspects internal HTTP request headers, elevating session classification to specific applications (e.g., web-browsing, outlook-web-online, custom-web-app). Security policies enforcing application-specific actions are re-evaluated immediately.
2. Intrusion Prevention (IPS): The Threat Prevention engine scans decrypted HTTP headers, URI strings, POST bodies, and cookies against thousands of vulnerability signatures targeting web servers (e.g., Apache, NGINX, IIS, WebLogic, Tomcat).
3. Antivirus & File Blocking: Files uploaded to internal web servers through HTTP POST or PUT requests are inspected for malware signatures and blocked if malicious.
4. Data Loss Prevention (DLP): Outbound HTTP responses from internal web servers are analyzed for sensitive data leaks, such as credit card numbers or Social Security numbers originating from compromised backend databases.

---

Architectural Comparison Reference