Chapter 16: SSL Transactions

This chapter includes the following topics:

SSL offloading

You can use FortiADC in a Layer-7 load-balancing topology to offload SSL decryption from the real server farm. In such a deployment, the FortiADC unit uses a copy of the real server certificate and its private key to negotiate the SSL connection. It acts as an SSL proxy for the servers, using the certificates and their private keys to:

When session data has been decrypted, you can use the FortiADC content rewriting, content routing, and web application firewall features.

Figure  81:  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 SSL offloading and maintain security, you must deploy the FortiADC appliance in a trusted network with a direct path to the real servers so that 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 physically located on the same locked rack.

In cases where traffic is forwarded along untrusted paths toward the real servers, you can use a real server SSL profile to re-encrypt the data before forwarding it to the real servers.

Basic steps:
  1. Import the X.509 v3 server certificates and their private keys that ordinarily belong to the backend servers, as well as any certificate authority (CA) or intermediate CA certificates that are used to complete the chain of trust between your clients and servers.
  2. Configure a local certificate group that includes the server's local certificate and the Intermediate CA group that contains the Intermediate CAs.
  3. Configure an application profile and a client SSL profile (if needed) that reference the local certificate group and specify 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.
  4. Configure a real server SSL profile that enables or disables SSL for the connection between the FortiADC unit and the real server. If enabled, specify the SSL/TLS versions and the list of SSL ciphers that can be used. Select this profile when you configure the real server pool.

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:
  1. Import a special Intermediate CA and its private key to the local certificate store that you have provisioned for SSL forward proxy operations.
  2. Configure an Intermediate CA group. (Optional)
  3. Configure a certificate caching object (or use the pre-defined one).
  4. 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.
  5. Configure all settings required for backend SSL.

Layer 7 deployments

Figure  82 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.

Figure  82:  Layer 7 SSL decryption by forward proxy

Table 164 summarizes the pros and cons of Layer 7 SSL decryption methods.

 Table 164:   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:

  • Some load balancing methods (only Round Robin and Least Connection are supported)
  • Some persistence methods (only Source Address, Source Address Hash, Source Address-Port Hash, and SSL Session ID are supported)
  • Client SNI Required option
  • Content routing

Layer 2 deployments

You can use FortiADC in a Layer 2 sandwich toplogy to offload SSL decryption tasks from FortiGate.

Figure  83 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.

Figure  83:  Layer 2 SSL decryption by forward proxy

Profile configurations

The application profile and client SSL profile determine the 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's SSL transaction capabilities. For example, in the case of SSL offloading, your goal is to eliminate SSL transactions on the real servers so that 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  84 illustrates the basic idea of client-side and server-side profiles.

Figure  84:  SSL profiles

Figure  85:   ……

The call-outs in Figure  86 have guidance for the two types of profiles used in a Layer 2 sandwich deployment.

In this deployment, the FortiADC 1 virtual server is of a Layer-2 HTTPS virtual server configuration. Its client SSL profile supports SSL forward proxy, including the special local signing 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. Because SSL is not enabled in the real server SSL profile, FortiADC 1 does not re-encrypt the SSL connection. (However, you can configure allowed SSL versions and ciphers in the client SSL profile, and you can also configure an SSL certificate verification policy to enforce rules and checks on the destination server certificate.) The client SSL 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  86:  Layer 2 sandwich profiles

For information on virtual server profile configuration objects, see Configuring Application profiles.

For information on real server SSL configuration objects, see Configuring real server SSL profiles.

Certificate guidelines

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 Manage and validate certificates.

SSL/TLS versions and cipher suites

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, ECDSA ciphers, and eNull ciphers.

Table 165 lists supported RSA ciphers.

 Table 165:   Cipher suites with RSA key exchange

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 166 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.

 Table 166:   Cipher suites with DHE/EDH key exchange

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 167 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.

 Table 167:   Cipher suites with EDCHE key exchange

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

Exceptions list

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.

SSL traffic mirroring

FortiADC supports mirroring packets (HTTPS/TCPS) to specified network interfaces. When the feature is enabled, SSL traffic will be mirrored to the specified ports by the virtual server after it has been decrypted.

The feature supports both IPv4 and IPv6. FortiADC can send traffic to up to four outgoing interfaces, including aggregated and VLAN interfaces. Mirrored traffic is transmitted as a single packet stream, using the original client-side source and destination IP address and port numbers. The source and destination MAC addresses are 0 (zero) in mirrored traffic. The feature requires a virtual server set to Layer 7 or Layer 2, with a profile configured for HTTPS or TCPS. It is supported on all FortiADC platforms.

Figure  87:  SSL traffic mirroring

Note that this feature is available via the CLI only, and has not yet been implemented on the GUI.

To enable this feature in a policy, execute the following command:

config load-balance virtual-server

edit vs-name

set ssl-mirror enable

set ssl-mirror-intf port1 port2

next

end