You often hear that TLS is the most important security protocol. Usually, the reasoning is that it’s very widely deployed and also that it works for many higher-level protocols. That’s certainly true, but for those who work more closely with these protocols there is another important aspect: we can learn so much about protocol design by carefully examining the evolution of TLS.
This month I released an updated version of SSL/TLS Deployment Best practices—my favourite SSL Labs publication—bringing the document up to date again. Given that the previous release was a long time ago (December 2014!), this version has quite a few changes and improvements.
In early 2009, SSL Labs was just this idea I had, born out of frustration with having to deal with a very complex subject without good documentation and tools. I wanted something that worked for me, and didn’t really anticipate that it could become as popular as it is today. The first version launched in the summer of that same year.
We are releasing an update to the grading criteria, version 2009l, to respond to the discovery of the DROWN attack. If a server is found to be vulnerable to DROWN it will be given an F, even though it might not support SSL v2 itself. (The nature of the DROWN vulnerability is such that servers that support SSL v2 can affect other servers, irrespective of supported protocol versions). You’ll find more information about our DROWN test here. Additionally, servers that support SSL v2 but don’t have any cipher suites configured are treated as if they had SSL v2 fully enabled.
This update also contains two fixes to our grading code, which we don’t consider to be changes to our grading criteria:
- Servers that have invalid HPKP information are not awarded A+.
- Servers that have an RSA key with exponent 1 are given an F.
Two days ago the DROWN vulnerability came to light, showing new ways to attack TLS. SSL Labs deployed tests for DROWN in the staging environment yesterday, and we’ll be pushing it to production shortly. Because DROWN is a tricky problem, the aim of this blog post is to provide an explanation of what we test for and how exactly.
A fascinating new research called DROWN has uncovered a previously-unknown vulnerability in SSL v2, the first ever version of SSL that was released in 1995 and declared dead less than a year later. Even though this old version of SSL is not used much these days, it continues to be supported by many servers. The especially bad aspect of this attack is that it can be used to exploit TLS, even in cases when client devices don’t support SSL v2, and sometimes even in cases when the servers don’t support SSL v2 (but use the same RSA key as some other server that does). The researchers estimate that up to 22% of servers could be impacted by this problem.
In October 2015, SSL Labs will start to fail (F) RC4-only servers. This change is a replacement for the second phase of our RC4 deprecation plan, which we announced in May 2015. We are adjusting our approach to avoid creating grading loopholes. (You can find out more about that here.)
The RC4 cipher is insecure and must be phased out. The IETF published RFC 7465 in February 2015 to formally deprecate RC4. In September 2015, Google, Microsoft and Mozilla announced that they will be removing RC4 from their browsers in early 2016. As a result of that change, RC4-only web sites will stop functioning in modern browsers. Our grading update will thus not only indicate the problems with RC4, but serve as an early warning system to help organisations migrate to better security in time.
Back in April we wrote about our plans for RC4 deprecation in SSL Labs. Our intention had been to deprecate RC4 in two steps, first in May and then again later in September. The initial change, which we carried out, was to cap site grades to C if they’re using RC4 with modern protocols (i.e., TLS 1.1 and TLS 1.2). The cap for those who use RC4 only with TLS 1.0 and earlier protocol versions (i.e., old clients) remained at B. Additionally, to ensure that the grading algorithm can’t be played, we changed the penalty for not supporting TLS 1.2 from B to C. This meant that those who were using RC4 with modern clients couldn’t improve their grade by disabling TLS 1.2.
For the second phase, the plan was to give F to those sites that use RC4 with modern protocols. However, when we started implementing this behaviour we realised that this would created another loophole: sites who got an F because of RC4 would be able to turn off TLS 1.2 to improve their grade (and get a C instead). This time we are not able to close the loophole by increasing the penalty for not supporting TLS 1.2.
As a result, there will be no change to the RC4 grading in September. We’ll determine how else we can encourage the removal of RC4 and make further grading changes later. As this week we will start a public discussion of the next-generation SSL Labs grading criteria, it’s likely that the RC4 changes will be considered as part of that discussion. To participate, please join the ssllabs-discuss mailing list.
As part of my job working on SSL Labs, I spend a lot of time helping others improve their TLS security, both directly and indirectly–by developing tools and writing documentation. Over time, I started to notice that deploying TLS securely is getting more complicated, rather than less. One possibility is that, with so much attention on TLS and many potential issues to consider, we’re losing sight of what’s really important.
That’s why I would like to introduce a TLS Maturity Model, a conceptual deployment model that describes a journey toward robust TLS security. The model has five maturity levels.