Announcing SSL Labs grading changes for 2017

At SSL Labs, we have a major review of our grading criteria about once a year. As the security of the ecosystem matures, our goal is to push forward and make the requirements [for a good grade] stricter. In many ways, this process of continuous improvement is what really matters to us.

According to our measurement in SSL Pulse, over 40% of the monitored sites have configuration that can be considered good. However, only about 3% of those get an A+, which is what everyone should be aiming for. So our goal with the design of the grading criteria is to push the number of A+ sites up.

In this blog post we will announce our short-term changes as well as outline some further changes that we will be making in 2017 and beyond. From the list below, the 3DES grading change will happen first. Other changes will follow. The main purpose of this blog post is to outline our grading directions so that organisations can start to plan their improvements.

Update (28 March 2017): The first batch of changes has been further documented in this follow-up blog post.

Penalty for using 3DES with modern protocols (C)

In late August, security researchers demonstrated an attack against ciphers that use 64-bit encryption blocks. 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. 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 and newer protocols. Such sites will have their scores capped at C. Sites that continue to support 3DES and keep it at the end of their ordered list of suites will not be affected.

Penalty for not using forward secrecy (B)

Forward security is a property of secure communication in which a compromise of a long term private key doesn’t affect any past encrypted conversations. In TLS, each deployment has to decide whether to provide forward secrecy. The very popular RSA key exchange, for example, doesn’t provide it. Because forward secrecy is one of the more important things to get right and we want to more emphasis on it; for that reason we will soon be requiring forward secrecy for the A grade.

We expect this to affect roughly 7% of the sites currently getting an A (currently at about 43%). If possible, we will not penalise sites that use suites without forward secrecy provided they are never negotiated with clients that can do better.

AEAD suites required for A+

Ever since the Lucky 13 attacks, the consensus in the security community has been that authenticated encryption is superior to CBC suites (as implemented in TLS). TLS 1.3 supports only AEAD suites. SSL Labs doesn’t currently reward the use of AEAD suites and we wish to correct this. In the next grading criteria update we will start requiring AEAD suites for A+. At some point in the future, AEAD suites will be required for A.

As with forward secrecy, we will not penalise sites if they continue to use non-AEAD suites provided AEAD suites are negotiated with clients that support them.

Protocol downgrade defenses

In April 2015, RFC 7507 introduced a new defense against voluntary protocol downgrade attacks; the full name of the standard is “TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks”. Because this defense closes a serious security loophole, SSL Labs requires that servers support the signalling value (TLS_FALLBACK_SCSV) to get an A+. The uptake was pretty good; according to the SSL Pulse results in August, 66% of all servers support this feature.

When we introduced this grading change, our intention was to eventually make SCSV support a requirement for A. In the meantime, POODLE came out, eventually leading to modern browsers generally removing voluntary protocol downgrade behaviour. At the moment, TLS_FALLBACK_SCSV doesn’t have a strong security value because the clients who support it won’t downgrade anyway. At the same time, the IIS doesn’t support RFC 7507, which means that anyone running their site on it can’t get an A+.

Given that the recent change to TLS 1.3 means that future protocol downgrades will be avoided, we will consider removing the requirement for TLS_FALLBACK_SCSV for A+.

Penalty for version intolerant servers

Initially, our intention was to introduce a penalty for servers intolerant to future TLS protocol versions. However, a change to the TLS 1.3 in the area of protocol version negotiation means that intolerant servers will no longer impede deployment of this protocol version. In that light, we are currently not planning to introduce a penalty for this problem.

Cipher grading adjustments

Our current algorithm for grading ciphers is not producing desired results, so we intend to introduce one or two explicit rules. First, all ciphers weaker than 128 (excluding 3DES) bits will result in an F grade. Additionally, servers that continue to support RC4—even if it’s not used with modern browsers—will be capped at C.

SHA1 deprecation

As you’re probably already aware, SHA1 has been deprecated for certificate signatures. In 2017, 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.

Further afield

The changes listed in the previous section will take place in the first half of 2017. We would like to take this opportunity to provide a rough outline of the future changes to SSL Labs grading criteria. The changes listed in this section will happen at some point in the future, when the time is right, but very likely not before Q3 2017. We will assess each change individually. We hope that this early notification will give organisations more time to plan ahead.

• HSTS preloading required for A+
• AEAD suites required for A
• HSTS required for A
• Sites with 3DES capped at B or C
• Harsher penalty for sites that continue to support RC4
• TLS 1.3 required for A+ (and for A, later, when the time is right)
• OCSP stapling (and, possibly, must-staple at some point) required for A+

Tags