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.

 

Good News! This site uses a unique or infrequently used 1024-bit Diffie-Hellman group. You are likely safe, but it's still a good idea to generate a unique, 2048-bit group for the site.
IPConnectedTLSInsecure DHE_EXPORTDHEChrome
Y.Y.Y.YXXNo

1024-bits

Not Supported

 

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:

Secure Client-Initiated RenegotiationSupported  DoS DANGER (more info)
 

This is resolved by disabling renegotiation in the clientssl profile.

Renegotiation

 Enabled

 

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:

Forward SecrecyNo  WEAK (more info)
 

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:

Good News! This site is safe from the Logjam attack. It supports ECDHE, and does not use DHE
 
IPConnectedTLSInsecure DHE_EXPORTDHEChrome
Y.Y.Y.YXXNo

Not Supported

ECDHE
 

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:

Secure Client-Initiated RenegotiationSupported  DoS DANGER (more info)
 

This is resolved by disabling renegotiation in the clientssl profile.

 

Renegotiation

 Enabled

 

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

www.f5.commy.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.

Published Mar 16, 2016
Version 1.0

Was this article helpful?

4 Comments

  • Recent F5 firmware supports 4096-bit RSA keys, which will boost www.f5.com on key exchange to 100%, at some slight performance cost. Not sure if this is rational, as it does have performance hit, and significant attacks against 2048 RSA keys would probably be better aimed at the CAs keys. Although arguably it still protects actual traffic better, making it harder to decrypted archived messages, so we went with the longest keys supported. I've put in the first proposal for using HPKP to avoid relying on these security lightweights like the CAs ;)
  • @Simon, I haven't read about any practical attacks against RSA 2048-bit keys. Given the performance cost is 5x, it's not that slight depending on your current load and hardware. Personally, I think effort is better spent in using only PFS ciphers, rather than investing deeply in 4096-bit keys. Wondering what's driving your adoption of 4096-bit beyond typical security paranoia. ;)
  • I agree Brian, it isn't clear 4096-bits keys are worth it, but hey it is nice to have one aspect of the F5 config score better than F5's ;) My paranoia is typical security paranoia (My predecessor in this role took part in the blacknet PGP key attack, and now he has all of facebook's resources at his disposal.....), plus demanding clients. For the service we put 4096-bit keys they already have PFS with common browsers, and have disabled DHE, and generally trying to stay ahead of the TLS issues. So when it comes to generate a key I use the longest I can. The hardware TLS termination is not currently anywhere near being the bottleneck, so the practical cost of longer keys is low unless traffic ramps up enormously. 2048 is now the recommended minimum length from NIST.