With the recent exposure of Heartbleed and POODLE vulnerabilities, we decided to take a good look at our environment and make sure that our TLS endpoints were up to scratch, this is what we found. For best results, there are 3 aspects to a TLS endpoint which should be considered. Software, certificates and configuration.
Software
Software is the easiest to get right and the one which most sysadmins will already be on top of. Simply put, software should be up to date. This means that you should be looking after your Operating system, the server itself (Apache, HAPproxy, IIS, Nginx) and your SSL/TLS implementation (OpenSSL, SChannel). Regular updates are important but one should also keep an eye on the media to update with patches for serious vulnerabilities ASAP.
Certificates
Again, keeping up to date with the latest recommendations and extensions helps. NIST and The Mozilla Foundation seem to be the two organisations most determined to move TLS forward and NIST regularly publish TLS usage guidelines.
One of the most common issues with certificates is the use of SHA-1 as a signing algorithm. SHA-1 cryptographic weaknesses discovered in 2005 mean that while expensive to break, SHA-1 is considered weak. From 2017, Google chrome will no longer trust sites with certificate chains which use SHA-1.
Another important consideration when buying a certificate is key size. 1024-bit keys should be considered dead. In September 2014 both Mozilla and Microsoft began phasing out 1024-bit key support. Mozilla’s change left over 30,000 websites untrusted. The choice today is between 2048 and 4096 bit keys. If you get traffic from low-power, mobile or IoT devices then 2048 is the way to go. The smaller key size means less of the device’s processing time and battery capacity will be spent on encryption. For server to server communication you might as well be doubly sure with a 4096-bit key. Remember that it’s not just your certificate that’s important but all of the certificates in your chain.
Configuration
Up to date software and strong certificates mean little if your servers are configured to use vulnerable protocols and cipher suites. POODLE put the final nail in SSLv3’s coffin as well as in Internet Explorer 6’s (hooray!!) since IE6 doesn’t support TLS1 or above. SSLv2 has been dead since SSLv3 was released way back in 1996. So make sure those 2 have been turned off.
Be sure to read your certificate providers cert installation docs and send clients intermediate certificates. Some clients (most notably Android and Linux) won’t automatically download intermediate certificates and won’t trust your certificate as a result.
Finally, you need to consider which cipher suites your TLS endpoint is allowing and in which order your server prefers those suites. A cipher suite is a combination of encryption, authentication, hashing and key exchange algorithms used to negotiate a secure TLS connection and determines the network protocol. Like the network protocols, some of the cipher suites have been found to be weak and should be disabled. Also, severs should prefer newer versions of TLS. Selection and ordering of cipher suites can be challenging. You want to make sure that as many clients as possible are able to connect, that the client’s connect with the best possible suite – preferably one which supports forward secrecy. You also need to make trade off decisions like whether to allow RC4 suites for TLS 1.0 and mitigate BEAST on the server or disable them to mitigate the growing concerns around RC4 weaknesses.
Summary
There’s more to SSL than installing a server and a cert. This isn’t intended to be a comprehensive guide to bulletproof TLS but if you consider the things mentioned above you should have an endpoint which is better than most.
For further reading I highly recommend the SSLLabs deployment best practices guide at https://www.ssllabs.com/projects/best-practices/index.html
