Figure 89: SSL offloading
This chapter includes the following topics:
You can use FortiADC in a Layer 7 load balancing topology to offload SSL decryption from the real server farm. In these deployments, FortiADC uses a copy of the real server certificate and private key to negotiate the SSL connection. FortiADC acts as an SSL proxy for the server, using the certificates and keys to:
When session data has been decrypted, you can use the FortiADC content rewriting, content routing, and web application firewall features.
Figure 89: SSL offloading
FortiADC forwards data unencrypted to the servers, and the servers can maximize performance because they are processing HTTP and not HTTPS transactions.
To realize the benefits of offloading and maintain security, you must deploy the FortiADC appliance in a trusted network with direct path to the real servers so the connection between the FortiADC and the real server does not have to be re-encrypted. For example, you connect FortiADC and the real servers through the same switch, and all are located physically in the same locked rack.
In cases where traffic is forwarded along untrusted paths towards real servers, you can use a real server SSL profile to re-encrypt the data before forwarding it to the real servers.
You can use SSL decryption by forward proxy in cases where you cannot copy the server certificate and private key to the FortiADC, either because it is impractical or impossible (in the case of outbound traffic to unknown Internet servers).
When SSL forward proxy is enabled, FortiADC is a proxy to both sides of the connection. The server certificate and private key used to negotiate the SSL connection with the client are dynamically derived from the certificate presented by the real server and chained with an Intermediate CA trusted by the client.
Figure 90 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.
Table 133 summarizes the pros and cons of Layer 7 SSL decryption methods.
Table 133: 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:
|
You can use FortiADC in a Layer 2 sandwich toplogy to offload SSL decryption tasks from FortiGate.
Figure 91 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.
The virtual server profile determines settings for the client-FortiADC connection; the real server SSL profile determines settings for the FortiADC-real server connection. This granularity gives you flexibility in how you leverage FortiADC SSL transaction capabilities. For example, in the case of SSL offloading, your goal is to eliminate SSL transactions on the real servers, so you can configure a server-side SSL profile that does not use SSL. Or it could be the case that the back-end real servers support only SSLv2, but you want to use the more secure TLSv1.2 for the client-FortiADC segment.
Figure 92 illustrates the basic idea of client-side and server-side profiles.
The callouts in Figure 93 have guidance for the two types of profiles used in a Layer 2 sandwich deployment.
In this deployment, the FortiADC 1 virtual server is a Layer 2 HTTPS virtual server configuration. Its virtual server HTTPS profile supports SSL forward proxy, including the special Intermediate CA. For Layer 2 virtual servers, the "real server" target is the next hop. In this case, the real server target is the FortiGate pool. In the real server SSL profile, SSL is not enabled, so FortiADC 1 does not re-encrypt the SSL connection. (However, you can configure allowed SSL versions and ciphers, and you can configure an SSL certificate verification policy to enforce rules and checks on the destination server cerfificate.) The virtual server HTTPS profile settings are used when re-encrypting the server response traffic in the return segment to the client.
The FortiADC 2 virtual server is a Layer 2 HTTP virtual server configuration. It receives unencrypted traffic from FortiGate. Its server pool is the next hop gateway. On its server side, FortiADC uses the real server SSL profile settings when it encrypts the outbound SSL connection and decrypts the inbound response traffic.
Figure 93: Layer 2 sandwich profiles
For information on virtual server profile configuration objects, see Configuring virtual server profiles.
For information on real server SSL configuration objects, see Configuring real server SSL profiles.
When a client browser requests an HTTPS connection to a web server, the server presents a server certificate to the client for verification. The client checks the content of the certificate against a local browser database of Certificate Authorities, and if it finds a match, the connection is made. If no match is found, the browser displays a warning that asks if you want to continue with the connection.
To avoid this warning, you must upload an Intermediate CA signed by one of the CA vendors that has its root certificates preinstalled in the web browsers. When the vendor issues you a local server certificate for your website, it typically includes the Intermediate CAs in your package.
For SSL offloading deployments, you create a local certificate group that references the local certificate for the server and its Intermediate CA group (a group that references all Intermediate CAs the vendor provided with your certificate package).
For SSL decryption by forward proxy deployments, you create a local certificate group that references any local certificate and an Intermediate CA group that includes the Intermediate CA and private key configuration you have provisioned for the SSL forward proxy operations.
|
You are not required to obtain SSL certificates from SSL vendors. You can use an enterprise certificate server (like Microsoft CertSrv) or open-source tools like OpenSSL or to generate them. Note, however, that a web browser will not trust the certificate unless it is associated with a certificate installed in the browser. If you use your own tools to generate the Intermediate CA, you must distribute that certificate to client browsers in whatever manner you typically do that—automatic update package from IT, manual distribution, and so on. |
For information on importing certificates and configuring certificate configuration objects, see Using certificates.
An SSL cipher is an algorithm that performs encryption and decryption. It transforms plain text into a coded set of data (cipher text) that is not reversible without a key. During the SSL handshake phase of the connection, the client sends a list of the ciphers it supports. FortiADC examines the client cipher list in the order it is specified, chooses the first cipher that matches a cipher specified in the virtual server configuration, and responds to the client. If none of the ciphers offered by the client are in the cipher suite list for the virtual server, the SSL handshake fails.
To see the list of ciphers supported by the browser you are using, go to a link maintained by the Leibniz University of Hannover Distributed Computing & Security (DCSec) Research Group:
https://cc.dcsec.uni-hannover.de/
FortiADC SLB profiles support a specific list of RSA ciphers, PFS ciphers, ECDHE ciphers, and eNull ciphers.
Table 134 lists supported RSA ciphers.
| Abbreviation | Cipher Suite | Protocol | Kx | Au | Enc | MAC |
|---|---|---|---|---|---|---|
| AES256-GCM-SHA384 | TLS_RSA_WITH_AES_256_GCM_SHA384 | TLS 1.2 | RSA | RSA | AESGCM(256) | AEAD |
| AES256-SHA256 | TLS_RSA_WITH_AES_256_CBC_SHA256 | TLS 1.2 | RSA | RSA | AES(256) | SHA |
| AES256-SHA | TLS_RSA_WITH_AES_256_CBC_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
RSA | RSA | AES(256) | SHA |
| AES128-GCM-SHA256 | TLS_RSA_WITH_AES_128_GCM_SHA256 | TLS 1.2 | RSA | RSA | AESGCM(128) | AEAD |
| AES128-SHA256 | TLS_RSA_WITH_AES_128_CBC_SHA256 | TLS 1.2 | RSA | RSA | AES(128) | SHA |
| AES128-SHA | TLS_RSA_WITH_AES_128_CBC_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
RSA | RSA | AES(128) | SHA |
| RC4-SHA | SSL_RSA_WITH_RC4_128_SHA | SSL 3.0 | RSA | RSA | RC4 | SHA |
| TLS_RSA_WITH_RC4_128_SHA | TLS 1.2, 1.1, 1.0 | RSA | RSA | RC4 | SHA | |
| RC4-MD5 | SSL_RSA_WITH_RC4_128_MD5 | SSL 3.0 | RSA | RSA | RC4 | MD5 |
| TLS_RSA_WITH_RC4_128_MD5 | TLS 1.2, 1.1, 1.0 | RSA | RSA | RC4 | MD5 | |
| DES-CBC3-SHA | SSL_RSA_WITH_3DES_EDE_CBC_SHA | SSL 3.0 | RSA | RSA | DES-CBC3 | SHA |
| TLS_RSA_WITH_3DES_EDE_CBC_SHA | TLS 1.2, 1.1, 1.0 | RSA | RSA | DES-CBC3 | SHA | |
| DES-CBC-SHA | SSL_RSA_WITH_DES_CBC_SHA | SSL 3.0 | RSA | RSA | DES-CBC | SHA |
| TLS_RSA_WITH_DES_CBC_SHA | TLS 1.2, 1.1, 1.0 | RSA | RSA | DES-CBC | SHA |
With RSA ciphers, the server's public RSA key is part of the server certificate and is typically very long lived. It is not uncommon for the same public key to be used for months or years. This creates a potential problem: if an SSL server's private key were to be leaked or stolen, all connections made in the past using that key would be vulnerable. If someone has recorded your SSL connections, they can use the stolen private key to decrypt them.
Table 135 lists supported Perfect Forward Secrecy (PFS) ciphers with DHE/EDH key exchange. With PFS, a fresh public key is created for every single connection.That means that an adversary would need to break the key for each connection individually to read the communication.
| Abbreviation | Cipher Suite | Protocol | Kx | Au | Enc | MAC |
|---|---|---|---|---|---|---|
| DHE-RSA-AES256-GCM-SHA384 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | TLS 1.2 | DH | RSA | AES256 | SHA384 |
| DHE-RSA-AES256-SHA256 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 | TLS 1.2 | DH | RSA | AES256 | SHA256 |
| DHE-RSA-AES256-SHA | TLS_DHE_RSA_WITH_AES_256_CBC_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
DH | RSA | AES256 | SHA256 |
| DHE-RSA-AES128-GCM-SHA256 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | TLS 1.2 | DH | RSA | AES128 | SHA256 |
| DHE-RSA-AES128-SHA256 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 | TLS 1.2 | DH | RSA | AES128 | SHA256 |
| DHE-RSA-AES128-SHA | TLS_DHE_RSA_WITH_AES_128_CBC_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
DH | RSA | AES128 | SHA |
| EDH-RSA-DES-CBC3-SHA | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
DH | RSA | 3DES | SHA |
| EDH-RSA-DES-CBC-SHA | TLS_DHE_RSA_WITH_DES_CBC_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
DH | RSA | DES | SHA |
Table 135 lists supported PFS ciphers with Elliptic curve Diffie–Hellman Ephemeral key (ECDHE) key exchange. ECDHE is significantly faster than DHE. The supported suites include both the Elliptic Curve Digital Signature Algorithm (ECDSA) and RSA key authentication (Au) algorithms.
| Abbreviation | Cipher Suite | Protocol | Kx | Au | Enc | MAC |
|---|---|---|---|---|---|---|
| ECDHE-ECDSA-AES256-GCM-SHA384 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | TLS 1.2 | ECDH | ECDSA | AESGCM256 | AEAD |
| ECDHE-ECDSA-AES256-SHA384 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | TLSv1.2 | ECDH | ECDSA | AES256 | SHA384 |
| ECDHE-ECDSA-AES256-SHA | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
ECDH | ECDSA | AES256 | SHA |
| ECDHE-ECDSA-AES128-GCM-SHA256 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | TLSv1.2 | ECDH | ECDSA | AESGCM128 | AEAD |
| ECDHE-ECDSA-AES128-SHA256 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | TLSv1.2 | ECDH | ECDSA | AES128 | SHA256 |
| ECDHE-ECDSA-AES128-SHA | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
ECDH | ECDSA | AES128 | SHA |
| ECDHE-ECDSA-RC4-SHA | TLS_ECDHE_ECDSA_WITH_RC4_128_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
ECDH | ECDSA | RC4 | SHA |
| ECDHE-ECDSA-DES-CBC3-SHA | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | SSL 3.0 TLS 1.2, 1.1, 1.0 |
ECDH | ECDSA | 3DES | SHA |
| ECDHE-RSA-AES256-GCM-SHA384 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | TLS 1.2 | ECDH | RSA | AESGCM256 | AEAD |
| ECDHE-RSA-AES256-SHA384 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 | TLS 1.2 | ECDH | RSA | AES256 | SHA384 |
| ECDHE-RSA-AES256-SHA | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | TLS 1.2 | ECDH | RSA | AES256 | SHA |
| ECDHE-RSA-AES128-GCM-SHA256 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | TLS 1.2 | ECDH | RSA | AESGCM128 | AEAD |
| ECDHE-RSA-AES128-SHA256 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 | TLS 1.2 | ECDH | RSA | AES128 | SHA256 |
| ECDHE-RSA-AES128-SHA | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | SSL 3.0 | ECDH | RSA | AES128 | SHA |
| ECDHE-RSA-RC4-SHA | TLS_ECDHE_RSA_WITH_RC4_128_SHA | SSL 3.0 | ECDH | RSA | RC4 | SHA |
| ECDHE-RSA-DES-CBC3-SHA | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | SSL 3.0 | ECDH | RSA | 3DES | SHA |
In addition, profiles support an eNull cipher option. This option represents all cipher suites that do not apply encryption to the application data (integrity check is still applied). The exact cipher suite used depends on the SSL/TLS version used. As an example, in SSL v3.0, eNULL includes NULL-MD5, NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, and some other non-encryption cipher suites.
Finally, profiles support a user-specified cipher list. You can specify a colon-separated list of OpenSSL cipher suite short names. The names are validated against the form of the cipher suite short names published on the OpenSSL website:
https://www.openssl.org/docs/manmaster/apps/ciphers.html
In some jurisdictions, SSL interception and decryption by forward proxy is disfavored for some types of websites or disallowed entirely. If necessary, you can use the L2 Exception List configuration to define destinations that should not have its sessions decrypted. You can leverage FortiGuard web filter categories, and you can configure a list of additional destinations.
You associate the L2 Exception List configuration with virtual servers that are in the path of outbound traffic. The virtual server evaluates whether an exception applies before processing the initial SSL client hello. If an exception applies, that connection is passed through, and it is not decrypted.
For information on creating the configuration, see Configuring an L2 exception list.
