SSL Profiles Part 5: SSL Options

John Wagnon, 2019-31-05

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.

1. SSL Overview and Handshake

2. SSL Certificates
3. Certificate Chain Implementation
4. Cipher Suites
5. SSL Options
6. SSL Renegotiation
7. Server Name Indication
8. Client Authentication
9. Server Authentication
10. All the "Little" Options

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.
 1. 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)
2. 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.
3. 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.
4. 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.
5. TLS D5 bug workaround: This option is a workaround for communicating with older TLSv1-enabled applications that
specify an incorrect encrypted RSA key length.
6. TLS block padding bug workaround: This option enables a workaround for communicating with older TLSv1-enabled
applications that use incorrect block padding.
7. 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).
8. 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.
9. 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.
10. 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.
11. 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.
12. No SSLv1 This options disallows the use of the SSLv1 protocol.
13. No SSLv2 This options disallows the use of the SSLv2 protocol.
14. No SSLv3 This options disallows the use of the SSLv3protocol.
15. No TLSv1: This options disallows the use of the TLSv1 protocol.
16. 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.
 17. 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.
18. 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.
19. 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.
20. 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. TLS block padding bug workaround: This option enables a workaround for communicating with older TLSv1-enabled
applications that use incorrect block padding
6. Passive close: This option either enables or disables the All Bugfixes Enabled option.
7. 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.
8. 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.
9. No SSLv1 This options disallows the use of the SSLv1 protocol.
10. No SSLv2 This options disallows the use of the SSLv2 protocol.
11. No SSLv3 This options disallows the use of the SSLv3protocol.
12. No TLSv1: This options disallows the use of the TLSv1 protocol.
13.
 13. 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.
14. 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.
15. 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_profiles.html?sr=29775670

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

F5 Networks, Inc. | 401 Elliot Avenue West, Seattle, WA 98119 | 888-882-4447 | f5.com

F5 Networks, Inc. F5 Networks F5 Networks Ltd. F5 Networks

Corporate Headquarters Asia-Pacific Europe/Middle-East/Africa Japan K.K.

[email protected] [email protected] [email protected] [email protected]

©2019 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in certain other
countries. Other F5 trademarks are identified at f5.com. Any other products, services, or company names referenced herein may be trademarks of
their respective owners with no endorsement or affiliation, express or implied, claimed by F5. CS04-00015 0113