SSL decryption by forward proxy
You can use SSL decryption by forward proxy in cases where you cannot copy the server certificate and its private key to the FortiADC unit because it is either impractical or impossible (in the case of outbound traffic to unknown Internet servers).
When SSL forward proxy is enabled, FortiADC becomes a proxy to both sides of the connection. The server certificate and its private key used to negotiate the SSL connection with the client are dynamically derived from the certificate presented by the real server and optionally chained with an Intermediate CA trusted by the client.
Basic steps:
- Import a special Intermediate CA and its private key to the local certificate store that you have provisioned for SSL forward proxy operations.
- Configure an Intermediate CA group. (Optional)
- Configure a certificate caching object (or use the pre-defined one).
- Configure a client SSL profile that enables SSL proxy, references the local certificate, and specifies the allowed SSL/TLS versions and list of SSL ciphers that can be used for the SSL connection between the client and the FortiADC unit. Select this profile when you configure the virtual server.
- Configure all settings required for backend SSL.
Layer 7 deployments
Layer 7 SSL decryption by forward proxy illustrates a Layer 7 SSL forward proxy deployment similar to the SSL offloading example—inbound traffic to your server farm. When the FortiADC virtual server receives the ClientHello message, it selects a real server and sends its own ClientHello to the server to set up its own SSL session with it (represented by the dashed line in the figure). FortiADC uses the certificate presented by the server to derive the certificate to present to the client. This derived certificate is signed by an Intermediate CA that is trusted by the client, so the client completes its handshake with the FortiADC, and FortiADC can decrypt the traffic.
Layer 7 SSL decryption methods summarizes the pros and cons of Layer 7 SSL decryption methods.
Layer 7 SSL decryption methods
| Method | Pros | Cons |
|---|---|---|
| SSL offloading |
Better performance. No feature limitations. In most cases, you do not need to maintain SSL functionality (certificates and keys, SSL ports) on the real servers. |
You must be able to copy the local certificates and private keys from the real servers. |
| SSL forward proxy | You do not need to copy the local certificates and keys from the real servers. Instead, you add only one Intermediate CA and private key to be used for all the HTTPS servers. |
Performance cost associate with SSL proxy operations and certificate re-signing. You need to maintain SSL functionality on the real servers. Incompatible with some features because the server must be selected before the client request is decrypted: Incompatible features include:
|
Layer 2 deployments
You can use FortiADC in a Layer 2 sandwich toplogy to offload SSL decryption tasks from FortiGate.
Layer 2 SSL decryption by forward proxy shows the topology. To decrypt traffic to and from external HTTPS destinations, you must use SSL forward proxy.
When the FortiADC virtual server receives the ClientHello message, it sends its own ClientHello to the destination server in order to fetch the server certificate so that it can be manipulated. The FortiGate and second FortiADC in the network path must be configured to pass-through this HTTPS traffic. FortiADC uses the server certificate to derive a certificate to present to the client. This derived certificate is signed by an Intermediate CA that is trusted by the client, so the client completes its handshake with the first FortiADC, and FortiADC decrypts the traffic.
In a sandwich deployment like this one, you do not want to re-encrypt the traffic until it egresses the second FortiADC. You control server-side SSL with the real server SSL profile configuration, discussed next.
