Update March 1, 2018: The completion of these changes is documented under Version 1.31.0 in the SSL Labs Changelog.
We are giving advance notification for following grading criteria changes applying from March 1, 2018: Not using forward secrecy, not using AEAD suites, and vulnerability to ROBOT. Update: This release also includes a grading change for some Symantec certificates.
We are releasing an update to the grading criteria, version 2009m, to respond to the discovery of the OpenSSL vulnerability CVE-2016-2107 announced in the OpenSSL Security Advisory [3rd May 2016]. This vulnerability can be exploited by MITM attacker using a padding Oracle attack to decrypt traffic when the connection uses an AES CBC cipher and the server supports AES-NI.
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:
SSL Labs v1.20.28 is now running in production. This version introduces a penalty for RC4-only servers, as previously announced.
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.