SSL Inbound Inspection
SSL Inbound Inspection protects internal servers from
threats posed by SSL/TLS traffic originating from an external server
or the Internet.
Use SSL Inbound Inspection to decrypt and inspect inbound
SSL/TLS traffic from a client to a targeted network server (any
server you have the certificate for and can import onto the firewall)
and block suspicious sessions. For example, suppose a malicious
actor wants to exploit a known vulnerability in your web server.
Inbound SSL/TLS decryption provides visibility into the traffic,
allowing the firewall to respond to the threat proactively.
SSL Inbound Inspection works similarly to
SSL Forward Proxy, except
that the firewall decrypts inbound traffic to internal servers instead
of decrypting outbound traffic from internal clients. The firewall
acts as a man-in-the-middle proxy between the external client and
the internal server and generates a new session key for each secure
session. The firewall creates a secure session between the client
and the firewall and another secure session between the firewall and
the server to decrypt and inspect the traffic.
Because the firewall is a proxy device, SSL Inbound Inspection
cannot decrypt some sessions, such as sessions with client authentication
or pinned certificates. Being a proxy also means that the firewall
does not support High Availability (HA) sync for decrypted SSL sessions.
On the firewall, you must
install the certificate and private key for
each server for which you want to perform SSL Inbound Inspection, unless
the certificate and private key is stored on an
HSM. The firewall 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 firewall forwards the server's 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 on the firewall. If your web server supports TLS 1.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)
to the firewall. Uploading the chain avoids client-side server certificate
authentication issues.
TLS 1.3 removes support for the RSA key exchange algorithm.
The firewall handles TLS 1.3 connections differently than TLS
1.2 connections. During TLS 1.3 handshakes, the firewall 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 firewall is sufficient if you correctly set up
your web server. For example, if your server’s leaf certificate
is signed by intermediate certificates, the chain of certificates
needs to be installed 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.
Before your server certificate expires or otherwise becomes invalid,
you should renew or obtain a new certificate. Then, import the certificate
and private key onto your firewall and add it to an SSL Inbound
Inspection policy rule before installing the same certificate onto
your web server. Updating your policy rule with a new certificate
while another is active on your web server prepares the firewall
to decrypt traffic to the server regardless of the certificate in
use.
When you are ready to deploy the new certificate, load
it onto your web server and check that you correctly installed it.
Installation of the new certificate does not impact existing connections.
The firewall verifies that the certificate in the Server Hello message
matches the new certificate in your 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. Log successful handshakes to view the server certificates
used in all inbound inspection sessions.
You can also create
policy rules to inspect traffic to servers that host various domains,
each domain with its own certificate.
(Panorama ™)
Support for multiple certificates in SSL Inbound Inspection policy
rules 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 a firewall running an earlier version, the policy
rule on the managed firewall inherits only the first certificate
from the alphabetically-sorted list of certificates.
Before
pushing your Decryption policy rule from Panorama, we recommend
you set up different
templates or
device groups for firewalls
running PAN-OS 10.1 and earlier to ensure you
push the correct policy rule and
certificate to the appropriate firewalls.
When you configure the
SSL Protocol Settings Decryption
Profile for SSL Inbound Inspection traffic, create separate profiles
for servers with different security capabilities. For example, if
one set of servers supports only RSA, the SSL Protocol Settings
only need to support RSA. However, the SSL Protocol Settings for
servers that support PFS should support PFS. Configure SSL Protocol
Settings for the highest level of security that the server supports,
but check performance to ensure that the firewall resources can
handle the higher processing load that higher security protocols
and algorithms require.
SSL Inbound Inspection does not support session resumption.
When you configure SSL Inbound Inspection, the proxied
traffic does not support DSCP code points or QoS.
