on
04-Jun-2013
06:00
- edited on
24-Mar-2023
12:04
by
LiefZimmerman
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.
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...
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.
The following is a complete list of the SSL Server-side Options:
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.
I used several sources when researching this article...here's a list of some that you might enjoy referencing:
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
Hi John,
The "Single DH Use" is applicable for only DHE or it is also applicable for ECDHE?
with regards, Saravanan