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.
If you have enabled
SSL Inbound Inspection using PFS key exchange algorithms, you must upload a certificate bundle (a
single file) to the firewall with your certificates arranged as
follows:
- End-entity (leaf) certificate
- Intermediate certificates (in issuing order)
- (Optional)Root certificate
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.
See Configure
SSL Inbound Inspection for details on enabling this feature.
When you configure SSL Inbound Inspection, the proxied
traffic does not support DSCP code points or QoS.
