A Transport Layer Security (TLS) certificate is a vital part of a balanced security breakfast, but millions of organizations are still eating Frosted Fruity Squiggles (with Extra Sugar inside!) and calling it a meal...and not even a tasty one at that.
You'd think configuring and deploying a TLS certificate securely would be an easy thing, but a quick look at Censys or Shodan reveals a gargantuan number of insecure TLS certs, including quite a few from organizations that really ought to know better.
TLS certificates protect the confidentiality and integrity of web traffic, email, and a growing number of other services, like DNS. While the X.509 system may be criticized as fundamentally broken, it remains an important and simple mitigation that should not be ignored, even if it is not a magic bullet that suddenly makes everything magically securitifically delicious.
Here are five tips to keeping the TLS leprechaun happy.
1. Use longer TLS keys
Factoring RSA primes as small as 1024 bits is a solved problem, which means an attacker can download your published public key, brute-force the private key, and then decrypt your traffic--or even impersonate your server. The solution: Use longer TLS keys.
A 2048-bit key is currently the industry standard, and you shouldn't be using anything less. Using a 3072-bit or 4096-bit RSA is not crazy talk for websites that don't have lightning fast performance requirements. Increasing RSA key length does come with a small performance hit that may or may not be noticeable to your users.
While ensuring a minimum RSA key length is critical to TLS cert security, there are so many other ways to attack TLS that key length is only the beginning of the journey, not the end.
2. Remove TLS 1 and TLS 1.1, if possible
Like SSL v2 and SSL v3, which should be deprecated with extreme prejudice, TLS v1 is no longer considered an acceptable best practice--even PCI DSS demanded PCI-compliant web sites remove TLS v1 support last year and urged merchants to disable TLS v1.1 as well.
In a section entitled, "What is the risk of using SSL/early TLS?", the folks at PCI write that "There are many serious vulnerabilities in SSL and early TLS that left unaddressed put organizations at risk of being breached. The widespread POODLE and BEAST exploits are just a couple examples of how attackers have taken advantage of weaknesses in SSL and early TLS to compromise organizations."
Security folk know that PCI/DSS isn't exactly cutting-edge security advice, but a minimum compliance baseline. Unless your enterprise has a need to support many very old devices, it's a good idea to remove support for TLS v1 and TLS v1.1 sooner rather than later.
TLS 1.3 support is still new, but it offers stronger security as well as performance improvements. The new spec was only finalized in August 2018, and adoption so far has been slow. Offering TLS 1.3 does no known harm and will downgrade to TLS 1.2 if the client does not support the newer protocol.
3. Remove support for old cipher suites, if possible
So many downgrade attacks, so little time. POODLE, FREAK, Logjam--the list goes on and on. To support older devices, many TLS implementations supported so-called "export encryption" from the 1990s--encryption deliberately kneecapped by the U.S. National Security Agency (NSA), which set limits on the strength of encryption that could be sold overseas. Tricking a web server into thinking a client only supports ancient, broken cipher suites was effective across the board until recently...and is still effective against millions of websites, according to a Censys search.
Take care to enable only secure ciphers, and if you must tolerate weaker ciphers, weigh the availability gain for a tiny percentage of users against the potential confidentiality and integrity loss for all your users.
For a list of cipher suites your TLS cert currently supports, and an analysis of which ones are considered safe, the Qualys SSL Labs online test is a good starting point.
4. Use shorter validity times
The easiest way to compromise a correctly configured and deployed TLS cert is to hack into the server and steal the private key. Regular key rotation ensures that key theft is not game over and compartmentalizes the damage to a maximum window of compromise. Experts recommend 60 to 90 days maximum, and Let's Encrypt enforces a 90-day maximum.
However, industry standard still permits key validity periods as long as two years (825 days), reduced as of 2018 from a previous maximum of three years. Don't do this. Regular 30-day key rotation would not be an insane suggestion at this point. Forcing an attacker to maintain persistence, or regularly hack your server to steal a new key, increases the likelihood that you'll catch them. While it may be impossible to defend against the most dangerous threat actors out there, you can and should make their life as difficult as possible.
5. Avoid wildcard certs across multiple devices
Hacking a server to steal a TLS key is extra easy if that private key is deployed across dozens of devices, including, say, a web server, email server, photocopier, printer, plus some random IoT device. Now the attack surface is so gigantic an attacker only needs to identify the weakest device and hack your photocopier instead of your web server.
The more copies of the private key there are, the easier it is for an attacker to steal the key and decrypt all the things. So, don't do that. Private keys should be unique to devices whenever possible.
Think your organization is immune? Even GCHQ, the UK secret police agency, managed to screw up a wildcard TLS deployment.
Poor TLS deployment practices say a lot about your organization--to attackers, who smell fresh meat, but also regulators and cybersecurity insurance companies, who scan the entire IPv4 range every week. If you can't be bothered to deploy your TLS certs right, what does the rest of your infrastructure look like? Lots of folks are looking, some of them are not so friendly. Put on your brave face.