SSL Forward Proxy
Focus
Focus
Network Security

SSL Forward Proxy

Table of Contents

SSL Forward Proxy

SSL Forward Proxy decryption decrypts outbound traffic so the NGFW can protect against threats in the encrypted traffic by proxying the connection between the client and the server.
Where Can I Use This?What Do I Need?
  • NGFW
  • Prisma Access
No requirements.
You can configure SSL Forward Proxy to decrypt and inspect SSL/TLS traffic from internal users to the internet. SSL Forward Proxy decryption prevents malware concealed as SSL encrypted traffic from being introduced into your corporate network. When you enable SSL Forward Proxy, an NGFW acts as a forward proxy. It creates two separate sessions: one between the client and the NGFW, and the other between the NGFW and the server. The NGFW uses certificates to transparently represent the client to the server and the server to the client, establishing itself as a trusted third party or meddler in the middle. As a result, the client believes it's communicating directly with the server, and the server believes it's communicating directly with the client. All web traffic goes through the NGFW, which applies decryption profiles and Security policy rules and profiles to the traffic.
(For details on certificates, see Keys and Certificates for Decryption Policies.)
Because the NGFW is a proxy device, it can’t decrypt certain sessions, such as those with client authentication or pinned certificates. It also doesn't support high availability (HA) sync for decrypted SSL sessions.
The following figure shows this process in detail.
  1. The internal client on your network attempts to initiate a TLS session with an external server.
  2. The NGFW intercepts the client’s SSL certificate request. For the client, the NGFW acts as the external server, though the actual secure session is established with the NGFW.
  3. The NGFW forwards the client’s SSL certificate request to the server to initiate a separate session with the server. To the server, the NGFW looks like the client, the server doesn’t know there’s a meddler in the middle, and the server verifies the certificate.
  4. The server sends the NGFW a signed certificate intended for the client.
  5. The NGFW analyzes the server certificate. If the server certificate is signed by a CA that the NGFW trusts and meets the policy rules and profiles you configure, the NGFW 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 NGFW does not trust, the NGFW generates an SSL Forward Untrust copy of the server certificate and sends it to the client. The certificate copy contains extensions from the original server certificate and is called an impersonation certificate because it is not the actual server certificate. If the NGFW does not trust the server, the client displays a warning message that the site they’re attempting to connect to isn’t trusted. Enable users to opt out of SSL decryption, so that the client can choose to proceed or terminate the session.
  6. The client verifies the NGFW’s impersonation certificate. The client then initiates a session key exchange with the server, which the NGFW proxies in the same manner as it proxies the certificates. The NGFW forwards the client key to the server and makes an impersonation copy of the server key for the client, so that the NGFW remains an “invisible” proxy and the client and server believe their session is with each other. Now, all parties have the certificates and keys required and the NGFW can decrypt the traffic.
  7. All SSL session traffic flows through the NGFW transparently between the client and the server. The NGFW decrypts the SSL traffic, applies Security policy rules and security profiles and decryption profiles to the traffic, reencrypts the traffic, and then forwards it.
When you configure SSL Forward Proxy, the proxied traffic does not support DSCP code points or QoS.