SSL Forward Proxy
Focus
Focus

SSL Forward Proxy

Table of Contents
End-of-Life (EoL)

SSL Forward Proxy

SSL Forward Proxy decryption decrypts outbound traffic so the firewall can protect against threats in the encrypted traffic by proxying the connection between the client and the server.
When you configure the firewall to decrypt SSL traffic going to external sites, it functions as an SSL forward proxy. Use an SSL Forward Proxy decryption policy to decrypt and inspect SSL/TLS traffic from internal users to the web. SSL Forward Proxy decryption prevents malware concealed as SSL encrypted traffic from being introduced into your corporate network by decrypting the traffic so that the firewall can apply decryption profiles and security policies and profiles to the traffic.
In SSL Forward Proxy decryption, the firewall is a man-in-the-middle between the internal client and the external server. The firewall uses certificates to transparently represent the client to the server and to transparently represent the server to the client, so that the client believes it is communicating directly with the server (even though the client session is with the firewall), and server believes it is communicating directly with the client (even though the server session is also with the firewall). The firewall uses certificates to establish itself as a trusted third party (man-in-the-middle) for the client-server session (for details on certificates, see Keys and Certificates for Decryption Policies).
Because the firewall is a proxy device, SSL Forward Proxy Decryption cannot decrypt some sessions, such as sessions with client authentication or pinned certificates. Being a proxy also means that the firewall does not support High Availability (HA) sync for decrypted SSL sessions.
The following figure shows this process in detail. See Configure SSL Forward Proxy for details on configuring SSL Forward Proxy.
  1. The internal client on your network attempts to initiate a TLS session with an external server.
  2. The firewall intercepts the client’s SSL certificate request. For the client, the firewall acts as the external server, even though the secure session being established is with the firewall, not with the actual server.
  3. The firewall then forwards the client’s SSL certificate request to the server to initiate a separate session with the server. To the server, the firewall looks like the client, the server doesn’t know there’s a man-in-the-middle, and the server verifies the certificate.
  4. The server sends the firewall a signed certificate intended for the client.
  5. The firewall analyzes the server certificate. If the server certificate is signed by a CA that the firewall trusts and meets the policies and profiles you configure, the firewall generates an SSL Forward Trust copy of the server certificate and sends it to the client. If the server certificate is signed by a CA that the firewall does not trust, the firewall generates an SSL Forward Untrust copy of the server certificate and sends it to the client. The certificate copy the firewall generates and sends to the client contains extensions from the original server certificate and is called an impersonation certificate because it is not the server’s actual certificate. If the firewall does not trust the server, the client sees a block page warning message that the site they’re attempting to connect to is not trusted, and if you Enable Users to Opt Out of SSL Decryption, the client can choose to proceed or terminate the session.
  6. The client verifies the firewall’s impersonation certificate. The client then initiates a session key exchange with the server, which the firewall proxies in the same manner as it proxies the certificates. The firewall forwards the client key to the server, and makes an impersonation copy of the server key for the client, so that firewall remains an “invisible” proxy, the client and server believe their session is with each other, but there are still two separate sessions, one between the client and the firewall, and the other between the firewall and the server. Now all parties have the certificates and keys required and the firewall can decrypt the traffic.
  7. All SSL session traffic between goes through the firewall transparently between the client and the server. The firewall decrypts the SSL traffic, applies security policies and profiles and decryption profiles to the traffic, re-encrypts the traffic, and then forwards it.
When you configure SSL Forward Proxy, the proxied traffic does not support DSCP code points or QoS.