SSL Inbound Inspection decryption decrypts inbound traffic
so the firewall can protect against threats in the encrypted traffic destined
for your servers.
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, if an employee is remotely connected
to a web server hosted on the company network and is attempting
to add restricted internal documents to his Dropbox folder (which uses
SSL for data transmission), SSL Inbound Inspection can ensure that
the sensitive data does not move outside the secure company network by
blocking or restricting the session.
On the firewall, you must install the certificate and private key
for each server for which you want to perform SSL inbound inspection.
You must also install the public key certificate as well as the
private key on each firewall that performs SSL inbound inspection.
The way the firewall performs SSL inbound inspection depends on
the type of key negotiated, Rivest, Shamir, Adleman (RSA) or Perfect
Forward Secrecy (PFS).
For RSA keys, 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
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.
For PFS keys using the Diffie-Hellman exchange (DHE) or Elliptic
Curve Diffie-Hellman exchange (ECDHE), the firewall acts as a man-in-the-middle
proxy between the external client and the internal server. Because
PFS generates a new key with every session, the firewall can’t simply
copy and decrypt the inbound SSL flow as it passes through, the
firewall must act as a proxy device.
The following figure shows how SSL Inbound Inspection works when
the key exchange algorithm is RSA. When the key exchange algorithm is
PFS, 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 must generate a new session key
for each secure session.
When you configure SSL Inbound Inspection and use a PFS
cipher, session resumption is not supported.