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:
  1. End-entity (leaf) certificate
  2. Intermediate certificates (in issuing order)
  3. (Optional)
    Root certificate
Uploading the file ensures that clients receive the complete certificate chain during SSL handshakes, avoiding client-side server certificate authentication issues.
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.

Recommended For You