Back in 2016 I documented how to get an A+ TLS score.
With minor changes this still works.
But times have changed. In particular older versions of TLS aren’t good; at a very least you must support nothing less than TLS1.2.
Consequences of limiting to TLS 1.2 or better
If you set your server to deny anything less than TLS 1.2 then sites like SSLlab tell us that older clients can no longer connect.
In particular:
Android 2.3.7
Android 4.0.4, 4.1.1, 4.2.2, 4.3
Baidu Jan 2015
IE 6 / XP
IE 7 / Vista
IE 8 / XP
IE 8-10 / Win 7
IE 10 / Win Phone 8.0
Java 6u45, 7u25
OpenSSL 0.9.8y
Safari 5.1.9 / OS X 10.6.8
Safari 6.0.4 / OS X 10.8.4
Now these are very old. We know that Win7 is still popular, so should we worry? Not so much; IE 11 on Win7 can support TLS1.2.
So I think it’s reasonable to disable anything lower.
Stronger ciphers
We also see that SSLlabs flag CBC ciphers as weak. Now this is debatable. CBC isn’t necessarily weak. But it’s historically had a lot of bad implementations, leading to variations of POODLE attacks (amongst others). It’s kinda expected that there will be yet another variation of POODLE on CBC. So SSLlabs flag these ciphers as weak, as an encouragement to move people off and onto stronger ciphers.
Unfortunately, it turns out there aren’t that many! At least not if you’re using RSA certs (which most people do).
In Apache/OpenSSL terms these ciphers are pretty much the only good ones:
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
Yes, that’s it. 4 of them.
If you run this through SSLlabs then it’ll be strong, but a number of clients won’t be able to connect.
IE 11 / Win Phone 8.1
Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 7 / OS X 10.9
Safari 8 / iOS 8.4
Safari 8 / OS X 10.10
(Notice IE11/Win7 isn’t on that list; it’ll happily do secure ciphers).
You need to decide if you want to support these older clients. If you do then these two CBC ciphers will make everything work:
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
Yes, these get flagged as weak, but now every client that supports TLS1.2 should work.
Complications
In an enterprise environment the client rarely talks directly to the server, especially not over the internet. There may be load balancers or WAFs in the path and these may be the ones that terminate the TLS connection. So their configuration is important.
In particular, F5’s BigIP servers can only do DH key exchange on 1024 bit keys. Which is considered weak. 2048bit is the minimum. Their rationale is that 2048bit keys require 5 times the computation than 1024bit keys. Which makes me wonder if the “big” in “BigIP” is now valid!
This is a problem. We have to choose between weak key sizes or potentially weak ciphers. In this scenario I recommend enabling CBC mode and ensuring you’re always on top of all patches; if a new POODLE variant is discovered, patch ASAP!
Conclusion
For my CentOS 7 Apache servers I now have the following configuration:
SSLProtocol TLSv1.2
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256
SSLlabs tells me this results in:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 4096 bits FS 128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 4096 bits FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
All the ciphers have forward secrecy, all are at least 128bit in strength, and all the clients that support TLS1.2 will connect.
Note the DH key is 4096bits in size. Why can’t BigIP support that?!