SSL Inbound Inspection
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 traffic.
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.
See Configure
SSL Inbound Inspection for details on enabling this feature.
