SSL security best practices

Vulnerabilities such as Heartbleed, POODLE, and FREAK are starting to alert the world of the importance of good security hygiene of our communication infrastructure. There’s never been so much scrutiny of the security of the Secure Socket Layer (SSL) and Transport Security Layer (TLS) protocols like today. We can trace this interest back as far as 2008, with no signs of slowing down. But, although most attention is on the protocol vulnerabilities, most organizations don’t realize that it’s their own actions that are proving to be bigger problems in practice.

In most companies—it seems—certificates are accounted for using spreadsheets. Security of secure servers is flagged up only when there is a major public discovery. Otherwise, little is done to get the most of the security mechanisms that are available today. We can’t really say that system administrators are to blame: TLS is notoriously flexible and configuring it correctly requires great time and effort. Furthermore, application-layer decisions can often negatively impact the security of otherwise properly configured servers.

In 2009, we began our work on SSL Labs (www.ssllabs.com), our research centre for SSL, TLS, and Internet PKI, with the aim to understand how these technologies are used around the world, and to provide tools and documentation to help everyone make the most of them. Although the list of best practices is long (we maintain a concise document called SSL/TLS Deployment Best Practices; it currently has 14 pages), over time we realized that there is small number of super-important things to get right.

Encrypt your entire web site

If you’re currently deploying encryption only on a part of your web site, you’re leaving a huge gap for your adversaries to exploit. Using so-called SSL stripping attacks, network attackers can gain control of any unencrypted user session and forever prevent it from moving to security. With full encryption, there’s no opportunity for network attackers to strike.

Almost equally importantly, you should deploy a new standard called HTTP Strict Transport Security, which ensures that your users’ browsers never attempt insecure communication, even when tricked by savvy attackers.

Deploy modern protocols and cipher suites

If you haven’t looked at your servers in a couple of years, chances are that, even they are not obviously insecure, they are running obsolete security protocols. If so, you should plan to upgrade as soon as possible to use new features such as TLS 1.2, forward security and authenticated encryption suites, and to phase out old features such as SSL 2, SSL 3, RSA key exchange, CBC suites, and RC4. Additionally, these days SSL configuration is used as a proxy to determine someone’s security posture. This is yet another reason to upgrade now and show that your security is strong!

Phase out your existing SHA1 certificates

This is not really a part of our best practices, but something you need to do today. The PKI ecosystem is currently transitioning away from weak SHA1 certificates. Although the hard transition deadline is at the end of 2016, some long-lived SHA1 certificates today might produce warnings in browsers. If you have SHA1 certificates that expire in 2016 or later, you should act now to replace them with SHA256 certificates. Alternatively, if you’re worried about cutting off some parts of your user base, continue to use SHA1 but with certificates that expire in 2015.

Monitor your site and mitigate known problems

Nothing stays perfectly secure. Even if you do your best today, a new disclosure tomorrow may break your security. The only way to deal with this problem is to continuously monitor your security posture and react when changes are detected. For SSL, we provide free assessment tools on our web site. Our server assessment tool will not only tell you about potential security problems, but also about issues that might impact your site availability. And, if you have a large number of servers to scan, we also have a free API to help you automate that task