The firewall can inspect SSL/TLS traffic destined for
internal servers to protect against threats in the encrypted traffic.
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 it 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.
The way the firewall performs SSL Inbound Inspection depends
on the type of key exchange in use—Rivest, Shamir, Adleman (RSA)
or Perfect Forward Secrecy (PFS). The Diffie-Hellman
exchange (DHE) and Elliptic Curve Diffie-Hellman exchange (ECDHE)
algorithms provide PFS. For the RSA key exchange, the firewall performs
SSL Inbound Inspection without terminating the connection. As the
encrypted session flows through the firewall, the firewall transparently makes
a copy of it and decrypts it so that the firewall can apply the
appropriate policy to the traffic. In other words, the firewall
passively observes and decrypts inbound traffic using the server’s
private key without being detected by the client and server.
For PFS key exchange algorithms (DHE or ECDHE), the firewall
acts as a man-in-the-middle proxy between the external client and
the internal server. Because PFS methods generate a new key for
every session, the firewall can’t simply copy and decrypt the inbound
SSL flow as it passes through and must act as a proxy device.
On the firewall, you must install the certificate and private key
for each server for which you want to perform SSL Inbound Inspection.
The TLS versions and key exchange algorithms that your web server
support determine how you should install the server certificate
on the firewall. If your web server supports TLS 1.2 and 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.
If your web server supports only TLS 1.2 and the RSA key
exchange algorithm, you can upload the server certificate and private
key alone because the connection is transparent. As
with TLS 1.3 connections, the certificate or certificate chain configured
on the web server is the same sent to the client.
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.
When you configure SSL Inbound Inspection and use a PFS
cipher, session resumption is not supported.
When you configure SSL Inbound Inspection, the proxied
traffic does not support DSCP code points or QoS.
The following figure shows how SSL Inbound Inspection works when
the key exchange algorithm is RSA. When a PFS key exchange algorithm
is in use, the firewall functions as a proxy (creates a secure session
between the client and the firewall and another secure session between
the firewall and the server) and generates a new session key for
each session.