SSL Labs Best Case Grades for Older TMOS Versions

Aspiring for that A+ rating on Qualys SSL Labs? F5er Brandon Frelich went to work to determine the best case scenarios for older versions of TMOS. Quite an engaging project, hopefully you enjoy reading through it as much as I did. For more info on the scoring process in general, reference John’s article.

Summary

Testing was completed with Qualys SSL Labs website Qualys SSL Labs against earlier versions of BIG-IP to determine what is the best case grade based across earlier versions. Customers may not yet have upgraded to a more recent release and I wanted to determine what if any limitations might exist. If a customer is concerned about their SSL Labs grade they can use this to balance their grade versus the support of the ciphers remaining to determine the best course of action. This exercise works through each of the base versions 10.2.4/11.2.1/11.4.1 and applies the latest HF as of Nov 2015 and then attempts to address different warnings presented by the site and apply appropriate changes to mitigate.

Essentially you will be capped via 10.2.4 and 11.2.1 to an A- due to their lack of PFS ciphers. With 11.4.1 you can get an A+. 

11.2.1

By default 11.2.1 will start with a failing grade due to the poodle attack (F5 Solution / CVE.) The only way to resolve this is by upgrading to at least HF13 (these results are from HF14.) Starting with HF14 and no modification to the DEFAULT, it is capped at a 'C' due to RC4 and 'B' by SSlv3.

This server uses SSL 3, which is obsolete and insecure. Grade capped to B. MORE INFO »

Certificate has a weak signature and expires after 2016. Upgrade to SHA2 to avoid browser warnings.  MORE INFO »

This server uses RC4 with modern browsers. Grade capped to C.

The server does not support Forward Secrecy with the reference browsers.  MORE INFO »

This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks.

So removing RC4 and SSLv3 will get you to a 'B' grade.

Certificate has a weak signature and expires after 2016. Upgrade to SHA2 to avoid browser warnings.  MORE INFO »

The server does not support Forward Secrecy with the reference browsers.  MORE INFO »

This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks.

But this doesn't leave you with too many cipher combinations.

By adding in the NATIVE ciphers we can get a couple more including some with Ephemeral Diffie-Helman RSA key exchanges although you will get a new warning as these are using relatively weak DH parameters. See below on the notes about this. A note though, if you do go down the NATIVE route, you need to remove the EXPORT ciphers.

This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.  MORE INFO »

Note: The B grade currently given to servers with 1024-bit DH parameters is not necessarily because such parameters are insecure. It's because we need to differentiate such servers from those that have stronger parameters and deserve a stronger grade. SSL Labs also has detection of common DH primes, but they currently don't affect the grade. It may be that such servers (those using common primes) get a worse grade in the future.

Additionally:

Logjam: PFS Deployment Guide has a logjam test which is one of the attacks possible given weaker parameters. Running this test provides.

So you won't get an 'A' but you can enable DHE ciphers but that will also limit you to a 'B' grade. So going back to DEFAULT and enabling HSTS via iRule gets us to a solid 'A-' again but not an 'A/A+'. The last warning message we get is:

This is resolved by disabling renegotiation in the clientssl profile.

With that disabled we're capped at an 'A-' still.

In conclusion, your best bet grade for 11.2.1 is going to be capped at a 'A-'. If your goal is grading the following cipher is your best case grade. "DEFAULT:!RC4:!SSLv3"

10.2.4

10.2.4, with HF12 applied, is similarly limited to an ‘A-‘ grade with the same cipher string as 11.2.1 HF13+. (“DEFAULT:!RC4:!SSLv3”)

It does have this remaining warning:

Remaining ciphers available:

11.4.1

By default 11.4.1 will start with a failing grade due to the poodle attack (F5 Solution / CVE.)

This server is vulnerable to the POODLE attack against TLS servers. Patching required. Grade set to F. MORE INFO »

The only way to resolve this is by applying at least HF6 (these results are from HF9.) With no modification to the default at HF6+, the grade is still capped at a ‘C’ due to RC4 and ‘B’ by SSLv3, however, by removing both   you will get to a grade of ‘A-.'

Certificate has a weak signature and expires after 2016. Upgrade to SHA2 to avoid browser warnings.  MORE INFO »

The server does not support Forward Secrecy with the reference browsers.  MORE INFO »

This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks.

So let’s see why:

We've added ECDHE key exchange methods to the DEFAULT. Testing NATIVE gives us the RSA DHE exchanges which will drop us back to a 'B' (see note above in 11.2.1)

Now it's a question of client support vs. security policy. Do you need to support DHE/RSA based key exchanges? As I'm going for the grade, I'll leave it at DEFAULT vs introducing other NATIVE cipher suites and having to remove them (EXPORT & DHE). Running the Logjam test again reveals the following results:

Also, we need to work on the order. This involves sorting. You need to remove ciphers to put them in the correct order you specify. To get a higher grade we need to prefer ECDHE over non Diffie-Helman. @STRENGTH at the end of the string would re-order all the ciphers while I'm choosing to just reorder the ECDHE according to strength while specifying the order of AES over 3DES. (3DES ranks higher in @STRENGTH over AES128).

In order for the BIG-IP to specify the order, the ciphers have to be removed. BE VERY CAREFUL. This could result in removing all the ciphers from the list. I also tested this with a couple clients to ensure it was returned properly.

Before: DEFAULT:!SSLv3:!RC4:-RSA:ECDHE+RSA+AES:RSA+AES:RSA+3DES

• TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
• TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
• TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
• TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
• TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) FS 112

After: DEFAULT:!SSLv3:!RC4:-RSA:ECDHE+RSA+AES:@STRENGTH:RSA+AES:RSA+3DES

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) FS 112
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
• TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
• TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
• TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
• TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
• TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112

So enabling HSTS gets us to a solid 'A' again but not an 'A+'. The last warning message we get is:

This is resolved by disabling renegotiation in the clientssl profile.

With that disabled we're capped at an 'A' still. So examining a known site which is getting an A+ and comparing.

www.f5.com	my.test-host.com

So it would seem even though I made the selection to ignore trust issues, I still appear to be capped at an 'A'. Also, it might be best to do a -ALL at the beginning to control ciphers from jumping to the head of the class after an upgrade.