Network Security
SSL Inbound Inspection
Table of Contents
Expand All
|
Collapse All
Network Security Docs
-
- Security Policy
-
- Security Profile Groups
- Security Profile: AI Security
- Security Profile: WildFire® Analysis
- Security Profile: Antivirus
- Security Profile: Vulnerability Protection
- Security Profile: Anti-Spyware
- Security Profile: DNS Security
- Security Profile: DoS Protection Profile
- Security Profile: File Blocking
- Security Profile: URL Filtering
- Security Profile: Data Filtering
- Security Profile: Zone Protection
-
- Policy Object: Address Groups
- Policy Object: Regions
- Policy Object: Traffic Objects
- Policy Object: Applications
- Policy Object: Application Groups
- Policy Object: Application Filter
- Policy Object: Services
- Policy Object: Auto-Tag Actions
- Policy Object: Devices
-
- Uses for External Dynamic Lists in Policy
- Formatting Guidelines for an External Dynamic List
- Built-in External Dynamic Lists
- Configure Your Environment to Access an External Dynamic List
- Configure your Environment to Access an External Dynamic List from the EDL Hosting Service
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Policy Object: HIP Objects
- Policy Object: Schedules
- Policy Object: Quarantine Device Lists
- Policy Object: Dynamic User Groups
- Policy Object: Custom Objects
- Policy Object: Log Forwarding
- Policy Object: Authentication
- Policy Object: Decryption Profile
- Policy Object: Packet Broker Profile
-
-
-
- The Quantum Computing Threat
- How RFC 8784 Resists Quantum Computing Threats
- How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
- Support for Post-Quantum Features
- Post-Quantum Migration Planning and Preparation
- Best Practices for Resisting Post-Quantum Attacks
- Learn More About Post-Quantum Security
-
-
-
- Investigate Reasons for Decryption Failure
- Identify Weak Protocols and Cipher Suites
- Troubleshoot Version Errors
- Troubleshoot Unsupported Cipher Suites
- Identify Untrusted CA Certificates
- Repair Incomplete Certificate Chains
- Troubleshoot Pinned Certificates
- Troubleshoot Expired Certificates
- Troubleshoot Revoked Certificates
SSL Inbound Inspection
SSL Inbound Inspection protects internal servers from threats posed by SSL/TLS
traffic originating from an external server or the internet.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
No requirements.
|
Configure SSL Inbound Inspection to decrypt and inspect inbound SSL/TLS traffic from clients to targeted network
servers and block suspicious sessions. For example, suppose a malicious actor wants to
exploit a known vulnerability with your web server. Inbound SSL/TLS decryption provides
visibility into the traffic, enabling the Next-Generation Firewall (NGFW)
to respond to the threat proactively.
SSL Inbound Inspection works similarly to SSL Forward Proxy, except the direction of
traffic it focuses on differs. The NGFW acts as a meddler in the middle
between an external client and an internal server. The NGFW creates two
separate and secure sessions: one between the client and itself, and another between
itself and the server. It also generates a new session key for each secure session. SSL
Inbound Inspection also supports SSL session resumption because the NGFW
functions as a proxy device.
The NGFW can't decrypt some sessions, such as sessions with client authentication
or pinned certificates, because it is a proxy device. It also doesn't support high
availability (HA) sync for decrypted SSL sessions.
SSL Inbound Inspection requires installation of the certificate and private
key of each internal server you want to protect onto the NGFW or
management platforms for NGFW and Prisma Access. The NGFW validates that the certificate sent by the targeted server during
the SSL/TLS handshake matches a certificate in your decryption policy rule. If there is
a match, the NGFW forwards the server certificate to the client
requesting server access and establishes a secure connection.
The TLS versions that your web server supports determine how you should install the
server certificate and key. If your web server supports TLSv1.2 and Rivest, Shamir,
Adleman (RSA) or Perfect Forward Secrecy (PFS) key
exchange algorithms and your end-entity (leaf) certificate is signed by
intermediate certificates, we recommend uploading a certificate chain (a single file).
Uploading the chain avoids client-side server certificate authentication issues.
TLSv1.3 removes support for the RSA key exchange algorithm.
TLSv1.3 connections are handled differently than TLSv1.2 connections. During TLSv1.3
handshakes, the NGFW sends the client the same certificate or certificate
chain that it receives from the server. As a result, uploading the server certificate
and private key to the NGFW is sufficient if you correctly set up your
web server. For example, if your server’s leaf certificate is signed by intermediate
certificates, install the chain of certificates on the server to avoid client-side
server authentication issues.
Multiple Certificate
Support
SSL Inbound Inspection policy rules support up to 12 certificates, enabling you to update
certificates for protected internal servers without incurring downtime. A valid
certificate must always be present in your policy rules and on your servers for
continuous decryption.
To add multiple certificates and maintain continuous decryption:
- Renew or obtain a new certificate before your server certificate expires or otherwise becomes invalid.
- Import the certificate and private key onto the NGFW or management platforms for NGFW and Prisma Access.
- Add the certificate to the SSL Inbound Inspection policy rule.
- Install the same certificate onto your web server. Load the certificate and check that you've correctly installed it.
Updating a policy rule with a new certificate while another is active on your web
server enables decryption of incoming traffic regardless of the certificate in use.
Installation of the new certificate doesn't impact existing connections. The NGFW verifies that the certificate in the Server Hello message
matches the new certificate in the decryption policy rule. If there isn't a match,
the session ends. The corresponding decryption log entry reports the
session-end reason as a mismatch between the firewall and server certificate. To
view the server certificates used in all inbound inspection sessions, log successful
TLS handshakes.
Additional Use Case: Create decryption policy rules to inspect traffic to servers that
host various domains, each domain with its own certificate.
(Panorama ™) Support for multiple certificates is unavailable in PAN-OS
versions earlier than PAN-OS 10.2. If you push an SSL Inbound Inspection policy rule
with multiple certificates from a Panorama management server running PAN-OS 11.1 to
an NGFW running an earlier version, the policy rule on the managed
NGFW inherits only the first certificate from the alphabetically
sorted list of certificates.
(Recommended) Before pushing your decryption policy rule from Panorama, set up different
templates or device groups for NGFWs
running PAN-OS 10.1 and earlier versions to ensure you push the correct policy rule and
certificate to the appropriate NGFWs.
Create separate decryption profiles for servers with different security
capabilities. Configure the SSL Protocol Settings for the highest level of security
that a server supports, but consider performance to ensure that the NGFW and Prisma Access resources can handle the higher processing
load that higher security protocols and algorithms require. For example, if a set of
servers supports only RSA, configure a decryption profile that exclusively supports
RSA. If a server supports both RSA and PFS, select RSA and PFS key exchange
algorithms.
When you configure SSL Inbound Inspection, the proxied traffic does not support
DSCP code points or QoS.