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? |
|---|
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.
