SSL Profiles Part 5: SSL Options

ltwagnon · ‎04-Jun-2013

Several months ago (ok, maybe lots and lots of months ago), Jason Rahm wrote a great series of Tech Tips that cover the BIG-IP LTM SSL profiles.

I'd like to take the baton and run a little further with the work he started. This next SSL profile article will dive into the specifics of the SSL Options that are offered in the BIG-IP LTM.

Why All The Options?

The LTM provides options for both client-side SSL and server-side SSL. So, why is it necessary to offer all these options? As you know, Internet browsers, operating systems, encryption algorithms, etc. sometimes have a hard time with compatibility and bugs. What!?!? Well, this is certainly true for SSL implementation. The LTM allows the behavior of the SSL library to be changed by setting several options. In order to keep traffic flowing as smoothly and efficiently as possible, the LTM is built with several OpenSSL-supported options that allow you to configure workarounds for defects and other unique settings. You can enable these workarounds and options as settings of an individual Client-side or Server-side SSL profile. This article will explore the details of what these options are and what they all mean. The following screenshot shows the location where you can enable or disable the various SSL options (navigate to Local Traffic > Profiles > SSL > Client | Server).

The default value for the Options setting is Options List. Keeping this default value enables only one option: Don't insert empty fragments.

As a reminder, when you enable the BIG-IP system to manage Client-side SSL traffic, the LTM terminates incoming SSL connections by decrypting the client request. The LTM then sends the request, in clear text, to a target server. Next, the LTM retrieves a clear-text response from the server and encrypts the request before sending the response back to the client. When you enable management of Server-side SSL traffic, the LTM re-encrypts a decrypted client request before sending it on to a target server.

Now, let's check out the Client-side and Server-side options...

Client-side Options

The following is a complete list and description of the SSL Client-side options that the LTM offers. It's important for each admin to enable/disable these options based on their specific network needs.

Netscape reuse cipher change bug workaround: This option handles a defect within Netscape-Enterprise Server 2.0.1. This defect only appears when connecting through SSLv2/v3 then reconnecting through SSLv3. If/when you connect this way, the cipher list changes. Initially, a connection is established with the RC4-MD5 cipher list. If the connection is resumed, it switches to the DES-CBC3-SHA cipher list. As a workaround, you can attempt to connect with a cipher list of DES-CBC-SHA:RC4-MD5 and so forth. Each new connection uses the RC4-MD5 cipher list, but any reconnection attempts use the DES-CBC-SHA cipher list. So when reconnecting, Netscape-Enterprise Server 2.0.1 always uses the first cipher in the cipher list. (Important note: as of OpenSSL 0.9.8q and 1.0.0c, this option has no effect)
Microsoft big SSLv3 buffer: Some Microsoft applications (old versions of Internet Explorer) use SSLv3 packets that are greater than 18k+5 bytes. This is prohibited by the SSLv3 specification. The big SSLv3 buffer option enables a workaround for communicating with these older Microsoft applications.
Microsoft IE SSLv2 RSA padding: Similar to the SSLv3 buffer, this option enables a workaround for communicating with older Microsoft IE versions that use non-standard RSA key padding.
SSLeay 080 client DH bug workaround: This option enables a workaround for communicating with older SSLeay-based applications (version 0.8.0) that specify an incorrect Diffie-Hellman public key length.
TLS D5 bug workaround: This option is a workaround for communicating with older TLSv1-enabled applications that specify an incorrect encrypted RSA key length.
TLS block padding bug workaround: This option enables a workaround for communicating with older TLSv1-enabled applications that use incorrect block padding.
No session resumption on renegotiation: This option specifies that, when the LTM performs renegotiation as an SSL server, it always starts a new session (e.g. session resumption requests are only accepted in the initial handshake).
Single DH use: This option creates a new key when using ephemeral (temporary) Diffie-Hellman parameters. This option is necessary if you want to prevent small subgroup attacks when the Diffie-Hellman parameters were not generated using strong primes (i.e. when using DSA-parameters). Remember, the strength of the Diffie-Hellman key agreement protocol depends on the strength of the prime number used to generate the shared secret key. If strong primes were used, you don't have to generate a new Diffie-Hellman key during each handshake, but it's highly recommend that you do. You should enable the Single DH use option whenever ephemeral Diffie-Hellman parameters are used. Update note: The Single DH use can be effective when mitigating the Logjam vulnerability. See this article for more information.
Ephemeral RSA: This option uses ephemeral (temporary) RSA keys during RSA operations (for more information on the RSA encryption algorithm, see the References section below). This is done when an RSA key can only be used for signature operations (more specifically under export ciphers with restricted RSA key length). By setting this option, the LTM always uses ephemeral RSA keys. This option breaks compatibility with the SSL/TLS specifications and can lead to interoperability problems with clients, so it's not recommended. Use it if you must, but if you can avoid it, it's recommended that you use ciphers with ephemeral Diffie-Hellman (EDH) key exchange instead.
Cipher server preference: When the BIG-IP system chooses a cipher, this option uses the server's preferences instead of the client preferences. When this option is not set, the SSL server always follows the clients preferences. When this option is set, the SSLv3/TLSv1 server chooses by using its own preferences. For SSLv2, the server sends its list of preferences to the client, and the client always chooses the cipher.
TLS rollback bug workaround: This option disables version rollback attack detection. During the client key exchange, the client must send the same information about acceptable SSL/TLS protocol levels as it sends during the first hello. Some clients violate this rule by adapting to the server's answer. For example, the client sends an SSLv2 hello and accepts up to SSLv3.1 (TLSv1), but the server only understands up to SSLv3. In this case, the client must still use the same SSLv3.1 (TLSv1) announcement. Some clients step down to SSLv3 with respect to the server's answer and violate the version rollback protection.
No SSLv1 This options disallows the use of the SSLv1 protocol.
No SSLv2 This options disallows the use of the SSLv2 protocol.
No SSLv3 This options disallows the use of the SSLv3protocol.
No TLSv1: This options disallows the use of the TLSv1 protocol.
PKCS1 check 1: This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect SSL server vulnerabilities. The SSLv3 specifications require that a modified PKCS1 padding be used in the RSA encryption operation to facilitate detection of rollback attacks against SSLv3 capable browsers when using the compatibility mode. Microsoft clients do not check for the modified PKCS1 packets, so they are vulnerable to this type of attack. This option is not recommended for normal use. The system ignores this option for client-side SSL processing.
PKCS1 check 2: This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect particular SSL server vulnerabilities. This option is not recommended for normal use. The system ignores this option for client-side SSL processing.
Netscape CA DN bug workaround: This option handles a defect regarding system instability. The system crashes or hangs if the following conditions are met: 1) the system accepts a Netscape browser connection, 2) the system demands a client certificate, 3) the system has a non-self-signed CA that does not have its CA in Netscape, and 4) the browser has a certificate. This option is in place to ensure the system does not crash or hang.
Netscape demo cipher change bug workaround: This option deliberately manipulates the SSL server session resumption behavior to mimic that of certain Netscape servers (see the Netscape reuse cipher change bug workaround description). This option is not recommended for normal use, and it is ignored for Server-side SSL processing.
Don't insert empty fragments: This option disables a countermeasure against a SSL 3.0/TLS 1.0 protocol vulnerability affecting Cipher Block Chaining (CBC) ciphers. These ciphers cannot be handled by certain broken SSL implementations. This option has no effect for connections using other ciphers. This is the default value for the Enabled Options list (see screenshot above).

Server-side Options

The following is a complete list of the SSL Server-side Options:

Microsoft session ID bug: This option handles the following problem with Microsoft session ID: When using SSLv2, if session-id reuse is performed, the session-id passed back in the server-finished message is different from the one decided upon.
Netscape challenge bug workaround: This option handles the following Netscape challenge problem: When Netscape-Commerce v1.12 is using SSLv2, it accepts a 32-byte challenge but then appears to only use 16 bytes when generating the encryption keys. Using 16 bytes is acceptable per the encryption standard, but it should be allowed to use 32 bytes for generating the key. According to the SSLv3 specification, you should use 32 bytes for the challenge when operating in SSLv2/3 compatibility mode. But, since the 32 byte key generation breaks this server, 16 bytes is the recommended way to go.
SSLRef2 reuse cert type bug workaround: This option handles the following SSL re-use certificate type problem: If R_SSL_reuse() is true, then the CERTIFICATE-TYPE, CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields should be 0. Some Netscape web servers do not implement this correctly.
Microsoft big SSLv3 buffer: Some Microsoft applications (old versions of Internet Explorer) use SSLv3 packets that are greater than 18k+5 bytes. This is prohibited by the SSLv3 specification. The big SSLv3 buffer option enables a workaround for communicating with these older Microsoft applications.
TLS block padding bug workaround: This option enables a workaround for communicating with older TLSv1-enabled applications that use incorrect block padding
Passive close: This option either enables or disables the All Bugfixes Enabled option.
Single DH use: This option creates a new key when using ephemeral (temporary) Diffie-Hellman parameters. This option is necessary if you want to prevent small subgroup attacks when the Diffie-Hellman parameters were not generated using strong primes (i.e. when using DSA-parameters). Remember, the strength of the Diffie-Hellman key agreement protocol depends on the strength of the prime number used to generate the shared secret key. If strong primes were used, you don't have to generate a new Diffie-Hellman key during each handshake, but it's highly recommend that you do. You should enable the Single DH use option whenever ephemeral Diffie-Hellman parameters are used. Update note: The Single DH use can be effective when mitigating the Logjam vulnerability. See this article for more information.
Cipher server preference: When the BIG-IP system chooses a cipher, this option uses the server's preferences instead of the client preferences. When this option is not set, the SSL server always follows the clients preferences. When this option is set, the SSLv3/TLSv1 server chooses by using its own preferences. For SSLv2, the server sends its list of preferences to the client, and the client always chooses the cipher.
No SSLv1 This options disallows the use of the SSLv1 protocol.
No SSLv2 This options disallows the use of the SSLv2 protocol.
No SSLv3 This options disallows the use of the SSLv3protocol.
No TLSv1: This options disallows the use of the TLSv1 protocol.
PKCS1 check 1: This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect SSL server vulnerabilities. The SSLv3 specifications require that a modified PKCS1 padding be used in the RSA encryption operation to facilitate detection of rollback attacks against SSLv3 capable browsers when using the compatibility mode. Microsoft clients do not check for the modified PKCS1 packets, so they are vulnerable to this type of attack. This option is not recommended for normal use. The system ignores this option for client-side SSL processing.
PKCS1 check 2: This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect particular SSL server vulnerabilities. This option is not recommended for normal use. The system ignores this option for client-side SSL processing.
Don't insert empty fragments: This option disables a countermeasure against a SSL 3.0/TLS 1.0 protocol vulnerability affecting Cipher Block Chaining (CBC) ciphers. These ciphers cannot be handled by certain broken SSL implementations. This option has no effect for connections using other ciphers. This is the default value for the Enabled Options list (see screenshot above).

Conclusion

When configuring protocol versions, you must ensure that the protocol versions configured for the BIG-IP system match those of the systems peer. So, protocol versions specified in the Client-side SSL profile must match those of the client, and protocol versions specified in the Server-side SSL profile must match those of the server. Also, as stated earlier, be sure to test each option on your network before you fully implement any/all of them. But, once you know which options to employ, take full advantage of the LTM's ability to provide these great features!

Well, that does it for SSL Options. The next article in this series will focus on SSL renegotiation and some of the attacks that are associated with it.

References

I used several sources when researching this article...here's a list of some that you might enjoy referencing:

AskF5 SSL Profiles Document: http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_concepts_11_0_0/ltm_ssl_profi...
OpenSSL SSL_CTX_set_options: http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#DESCRIPTION
SSL implementation bugs: http://www.dcs.ed.ac.uk/home/crypto/SSLeay/vendor-bugs.html
Diffie Hellman encryption protocol: http://www.rsa.com/rsalabs/node.asp?id=2248
RSA encryption documents (to include PKCS #1): http://www.rsa.com/rsalabs/node.asp?id=2422
Cipher Block Chaining description: http://www.rsa.com/rsalabs/node.asp?id=2171
(updated May, 2015) Remediating Logjam: https://devcentral.f5.com/s/articles/remediating-logjam-an-irule-countermeasure

Ludovic_G_11565 · ‎13-Oct-2017

This page is missing the following options : * NoTLSv1.1 * NoTLSv1.2

I'm trying to figure in which version of the Big IP F5 LTM version these have been introduced.

Currently on one of our F5, we have an outdate version BIG-IP 11.2.1 Build 1312.23 Engineering Hotfix HF14. On this version when activating the following options : * NoSSLv2 * NoSSLv3 * NoTLSv1 The client is not able to connect, as TLSv1.1 and TLVSv1.2 are blocked because of options * NoTLSv1

In later versions, BIG-IP 11.5.4 Build 2.0.291 Hotfix HF2, the options : * NoTLSv1.1 * NoTLSv1.2

Are available.

Moreover, due to internal company reasons, we cannot update the version of firmware on the outdate Big IP F5.

Can I manage, using an iRule to do the same ?

Currently, I did see some iRules which redirect unsecure protocol to specific pages, but this is not what I want to achieve, ideally I would like to be able to handle SSL negotiation and refuse TLSv1.0 and TLSv1.1.

Thank you! Ludovic

Saravanan_M_K · ‎15-May-2018

Hi John,

The "Single DH Use" is applicable for only DHE or it is also applicable for ECDHE?

with regards, Saravanan

DevCentral