About two months ago we announced that we will be making many grading changes in 2017. In this email we will highlight only the first batch of changes, but most of all we want to introduce a new feature that will help our users stay informed as we continue to evolve our grading system; it’s our grade-change notification system.
Update (27 Jan 2017): Clarified that the penalty applies equally to all ciphers that use 64-bit block size, not just 3DES.
Update (8 Feb 2017): For a period of time this blog post showed that the 3DES penalty applied only to TLS 1.2. This was incorrect; it applies to both TLS 1.1 and TLS 1.2, and that’s how the algorithm has been working from the beginning. In practice, there probably wasn’t a difference because there are very few clients that support TLS 1.1 but not TLS 1.2. We also apply the same penalty (C) to servers that don’t support TLS 1.2.
New grade-change notification system
Even though we announce our grading changes well in advance (one month at minimum, but we try to give more notice), not all of our users follow our blog posts. So, for them, we built a special grade-change notification system to alert them about an impeding grade change.
With the new system in place, we’re now showing two grades in parallel. The old grade, which is still valid, and the next grade. Whenever possible, we will include the exact changes date as well as a link to a blog post (like this one) to explain them. Here’s a mockup of what we’re talking about:
We hope that this new system is help our users smoothly improve their configuration and always have the grade they wish to have.
January 2017 grading changes
This month we’re making the following changes. Our grading guide has been updated accordingly.
As you’re probably already aware, SHA1 has been deprecated for certificate signatures. In 2017, all browsers will stop trusting web sites that continue to use this weak hash function for signatures. In line with the industry, we too will distrust such sites. In line with the browser behaviour, SSL Labs will no longer trust SHA1 certificates, giving sites that continue to use it a T.
We are aware that some companies continue to use SHA1 certificates only with clients that don’t support SHA2. We’ve incorporated detection of such behaviour in our assessments; they shouldn’t be penalised.
Firefox will be the first browser to stop trusting SHA1, on 24 January. You’ll find a good overview of the SHA1 deprecation process in this article.
Penalty for using 3DES with TLS 1.1 or newer (C)
In late August, security researchers demonstrated an attack against ciphers that use 64-bit encryption blocks. The attack has been called Sweet32. The attack is not practical because it requires a very large amount of traffic, but it’s a good reminder that older and weaker ciphers need be retired as a matter of routine. In TLS, that means avoiding 3DES (EDIT 27 Jan: and other ciphers that use 64-bit blocks, for example IDEA). Now, for sites that need to support an old user base completely retiring 3DES might not be possible (hint: Windows XP), but there’s no reason to use this cipher with modern browsers. To that end, we’ll be modifying our grading criteria to penalise sites that negotiate 3DES with TLS 1.1 or TLS 1.2. Such sites will have their scores capped at C. We are aware that most servers don’t allow per-protocol cipher suite configuration, but that shouldn’t be a problem in this case. Sites that negotiate strong cipher suites with modern clients will not be affected if they support 3DES. This can be achieved by enforcing suite preference at server level and keeping 3DES at the end of the list.
Cipher grading adjustments
Finally, we’re also making a change to correct a flaw in the grading criteria that didn’t sufficiently penalise the use of weak cipher suites. Starting with today, all servers that support cipher suites weaker than 112 bits will be given an F grade.