As promised in my last post on F5 load-balancers, this weeks issue of the never-ending guide on how to keep your F5 Big-IPs in the good graces of Qualys SSL Labs will deal with TLSv1.3 demanding that we use cipher groups instead of cipher strings, and how to set a custom cipher group.

Before We Begin

Note that TLSv1.3 is only supported on Big-IP systems running software version 14.x, 15.x or newer. Furthermore, the support in version 14 is only for the experimental standard, while version 15 onwards supports the final version of TLSv1.3. The newest version also supports a couple more ciphers than the older version. Therefore my recommendation is to upgrade you F5 Big-IP to version 15 before going forward.

Back in my guide on fixing weak ciphers, we used the following cipher string kindly provided by Mr Kai Wilke of F5.

!SSLv2:!EXPORT:!DHE+AES-GCM:!DHE+AES:!DHE+3DES:ECDHE+AES-GCM:ECDHE+AES:RSA+AES-GCM:RSA+AES:ECDHE+3DES:RSA+3DES:-MD5:-SSLv3:-RC4

This cipher string is still quite alright, but it includes a lot of legacy ciphers (3DES especially) that are considered rather weak these days (as of November 2019).

Here’s how our site is looking on SSL Labs with the old cipher string (TLSv1.3 not enabled at this point). As you can see, very little green and a lot of orange. Additionally, these’s old ciphers don’t actually provide any more client support, as everything that supports TLSv1.2 also supports much more modern ciphers.

If we use the f5_secure cipher group as I recommended in last week’s guide we’ll get the following output.

A bit less orange, a bit more green, no 3DES, but far from excellent still. Hopefully we can do better.

Creating Custom Cipher Rules

There are a couple ways to go about this, but I’m going to show you how to create several custom cipher rules, which we’ll combine into a final cipher group that we can use for our SSL profile.

First we need to establish what ciphers we’ll use for our custom cipher group. I’ve opted to use two sources, OWASP and the Mozilla foundation, and combine them using cipher rules into a single cipher group.

We’ll start by defining cipher rules for these.
Go to Local Traffic -> Ciphers -> Rules

OWASP

OWASP has a nifty cheat sheet of ciphers in preferred order. We’ll be using the B-list, since it provides excellent security with compatibility that’s on par with TLSv1.2, so we shouldn’t loose any client support by using this cipher set.

The following string is the OWASP-B reformatted into F5 compatible names. F5 largely uses the same naming scheme as OpenSSL, but there are some differences (mainly TLS is TLS13, dashes instead of underscores etc.), and the Big-IP doesn’t take kindly to any discrepancies.

TLS13-AES256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256

Select Create, give your rule the name owasp_b, a good description, and paste the cipher string above into the Cipher Suites field. The generated list of ciphers should be as follows.

Mozilla

Mozilla publishes a similar set of lists, and we’ll use the intermediate list for our experiment, as it also supports TLSv1.2 clients, and adds a couple more modern ciphers for TLSv1.2 that OWASP doesn’t cover.

TLS13-AES128-GCM-SHA256:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305-SHA256:ECDHE-RSA-CHACHA20-POLY1305-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

Create a new cipher rule, name it mozilla_intermediate, and add the cipher string above to it. The end result should look like this:

Diffie Hellman Key Exchange

But, there’s another problem. Since F5 Big-IP doesn’t implement 2048-bit DH key exchanges yet becuase it doesn’t need to due to how it rotates it’s keys, we’ll need to disable all DHE cipers, or our grade will get capped to B, again. This is a limitation to the SSL Labs test, it can’t test the key rotation, so it’ll show all 1024-bit DH keys as weak, regardless if they actually are or not.

DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256

To make our cipher group easy, we’ll add these ciphers to a separate rule that we’ll use to exclude these when forming the final group.

Create a new cipher rule, and name it dhe_ciphers and add the cipher string above to it. It should look something like this.

Creating Custom Cipher Groups

Now we’re ready to create our own custom cipher group that will bring all our cipher rules into a large ball of happy secure ciphers.

Head over to Local Traffic -> Ciphers -> Groups and select the Profile you’d like to edit.

Create a new group and name it secure_ciphers or something equally catching, and give it a description. Add the mozilla_intermediate and owasp_b cipher rules to Allow the following: and dhe_ciphers to Exclude the following from the Allowed List:
Also select secure from the Order option list to make the Big-IP present the certificates in order of strength instead of whatever logic default implies. This has an impact on performance, but you can be sure that every connection uses the strongest cipher that both the client and the Big-IP supports.

It should look something like this:

If all your rules were populated correctly, and you assembled your group correctly, the Big-IP should build the following cipher list for you

If everything looks like it should, select Finished at the bottom of the page.

However, we’re not done yet, we still need to change our SSL profiles to use this new cipher group, so go over to Local Traffic -> Profiles -> SSL -> Client and select the Profile you’d like to edit. Scroll down to Ciphers and select Cipher Group and then secure-ciphers from the drop-down menu.

After that, select update at the end of the page to update your SSL profile.

Checking our work

Now we can go back to SSL Labs, and check our grade again, and you should find a lot higher green to orange ratio.

So, now you might wonder, why are we still allowing the use of ECDHE_RSA_WITH_AES_256_CBC_SHA384 and ECDHE_RSA_WITH_AES_128_CBC_SHA256?
The answer is very simple, backwards compatibility. If we remove these CBC ciphers from the list, we’ll effectively block all systems running IE11, mostly affecting Windows 7 since it doesn’t support anything more modern than CBC if you’re using IE, as well as some quite old iOS and OSX versions. My personal view is that Windows 7, even though it’s soon to be End-of-Life, is still too prevalent to completely knock it of the map, especially if your clients are consumers. If you control all the clients accessing your Big-IP, then by all means, remove these ciphers from the rules we created earlier, but don’t be surprised at what legacy systems you didn’t know about you might have on your network.

But, you might ask, why are these marked as weak by Qualys? This has to do with the fact that quite recently, there were 4 vulnerabilities in CBC discovered in short succession of each other. Even though Qualys SSL Labs tests for these separately, they decided that this influx of vulnerabilities in CBC was enough to mark ciphers using it as weak, which is something I personally agree with. In this jungle of cipher sets, the SSL Labs test has become something of a standard for web servers, and them marking something as “weak” will have a impact on what people use in the long term.

Also check out the other instalments of this series:

Fixing SSL Labs Grade on F5 Big-IP – Certificate Chains
Fixing SSL Labs Grade on F5 Big-IP – Weak Cipher Suites
Fixing SSL Labs Grade on F5 Big-IP – ECDH public server param reuse
Fixing SSL Labs Grade on F5 Big-IP – Disabling TLSv1 and TLSv1.1
Fixing SSL Labs Grade on F5 Big-IP – Enabling TLSv1.3

Categories: Networks, Tech

Tags: cipher, f5, f5 big-ip, https, SSLLabs, TLS, tls ciphers, TLSv1.2, TLSv1.3