SSL
When you configure the Virtual Traffic Manager to manage traffic using the SSL protocol, the Virtual Traffic Manager does not automatically decrypt the traffic. The SSL protocol type is used for SSL pass-through, without modification.
You can use the “SSL Session ID” persistence type to load-balance SSL connections across a pool, ensuring that connections with the same SSL session ID are sent to the same back-end server. This is an important consideration because SSL servers do not generally share SSL session IDs with each other. So if a client attempts to re-use an SSL session ID, but is directed to a new server, it would then need to renegotiate its SSL session. This is compute-expensive and will add load to your SSL server farm. In fact, without SSL session ID persistence, adding more SSL servers to your cluster can reduce performance because SSL sessions need to be renegotiated more frequently.
If you want to decrypt SSL traffic and process it using the internal protocol (such as HTTP), you should configure your virtual server to use the internal protocol, and enable SSL decryption in the virtual server configuration settings (for details about configuring SSL, see SSL Decryption and SSL Encryption).
Protecting the SSL Handshake
To protect against a potential Denial-of-Service (DoS) attacks, place a limit on the size of the peer handshake message clients attempt when negotiating an SSL connection. Use the ssl!max_handshake_message_size setting in System > Global Settings > SSL Configuration.
The value of this setting determines the maximum size of SSL handshake messages accepted for SSL connections. Any handshake message indicating a size larger than this setting will cause the SSL connection to fail and will be logged as a potential DoS attack in the event log. The default value of 10 KiB should be able to accept a chain of 5 certificates, which should be more than sufficient for typical SSL set-ups. Specifying a value of 0 (zero) denotes that there is no limit to the size of SSL handshake messages handled by the Virtual Traffic Manager.
SSL Connection Renegotiation Protection
Both SSL 3.0 and TLS (Transport Layer Security) protocols allow either the client or server to initiate renegotiation of the secure connection. This might be to establish new cryptographic parameters by which the connection will be governed.
During renegotiation, the secure connection becomes potentially vulnerable to interception by an attacker who might seek to inject traffic as a prefix to the client's interaction with the server. This mechanism, known as a Man-in-the-Middle (MitM) attack, can be used to set up a new client connection from the attacker, fooling the target server into believing that the initial data transmitted by the attacker is from the same entity as the original client.
Furthermore, renegotiation can be used to carry out a Denial of Service (DoS) attack because it poses a much higher load on the server than on the client. A client could simply request a re-handshake at a very high rate causing a very high computational burden on the server.
RFC-5746 (http://tools.ietf.org/html/rfc5746) introduces a TLS extension that prevents the MitM attack by cryptographically tying renegotiations to the client that is performing it. However, the introduction of this extension does not necessarily prevent or protect from a DoS attack.
The RFC-5746 renegotiation indication extension was found to be vulnerable to the Triple Handshake Attack, described in RFC-7627 (http://tools.ietf.org/html/rfc7627). That RFC also introduces another TLS extension to defend against this attack by the use of an "extended master secret" for TLS versions 1.0 - 1.2.
To configure how the Virtual Traffic Manager handles a potential renegotiation handshake, select the required setting in ssl!allow_rehandshake, located in System > Global Settings > SSL Configuration. The available options are:
Setting | Description |
|---|---|
Always allow | Renegotiation is always allowed, even if the client lacks support for RFC-5746 or RFC 7627, but without any form of protection against intervention by a third party. This setting is NOT RECOMMENDED, and could leave your system open to MitM or DoS attacks. |
Allow safe re-handshakes [default setting] | This includes the case in which the client supports RFC-5746 and the case that no data has yet been transmitted over the connection. Since the aforementioned attack consists of pre-pending plain text, if no data has yet been received, the re-handshake is safe. This is of limited use as from the client's perspective, the re-handshake is actually the first handshake, so the client cannot know whether the connection is under attack. This option is therefore mostly provided for backward compatibility with clients that have yet to be upgraded to support RFC-5746. Renegotiation is also prevented following the resumption of a session that was not originally created during a handshake using the extended master secret extension. Note that since this setting allows re-handshakes it still leaves an installation potentially open to the DoS attack mentioned above. |
Only if client uses RFC 5746 (Secure Renegotiation Extension) | Renegotiation handshakes are only allowed if the client supports Secure Renegotiation as defined in RFC-5746. Renegotiation is prevented following the resumption of a session that was not originally created during a handshake using the RFC 7627 extended master secret extension. Note that since this setting allows re-handshakes it still leaves an installation potentially open to the DoS attack mentioned above. |
Never allow | Reject all attempts at a renegotiation handshake. This is the most secure method as it protects against both MitM and DoS attacks. However, service failure is possible if, for example, some aspect of your installation depends on client-side renegotiation. |
If SSL 3.0/TLS re-handshakes are allowed, you can use the ssl!min_rehandshake_interval setting to define the minimum time interval (in milliseconds) permitted between handshakes on a single SSL 3.0/TLS connection. The time interval starts when the opening handshake is initiated and is reset at the beginning of every re-handshake. To disable the minimum interval for handshakes, use a setting of 0 (zero).
If the Virtual Traffic Manager acts as an SSL server (ssl_decrypt is set to "Yes" in a virtual server) and a renegotiation is triggered by the Virtual Traffic Manager itself via the TrafficScript function ssl.requirecert(), the resulting renegotiation will not be subject to the rate limit.