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.

There is additional problem with HSTS preloading. In our company case:
a) server1.example.com should always be accessed by https,
b) server2.example.com does not have https implemented and it is not planned to have one, because it is only a web page with completely non-sensitive data.

In case of HTST preloading I tried to preload server1.example.com and got error, that only example.com can be preloaded, because if subdomains would be preloaded then preload list may get pretty much too big.

HSTS preloading is useful only if all of the web servers can/should accept https.

P.S. I agree checking domain’s DNSSEC and DANE would be better way. This is nice web test site: https://en.internet.nl/

In your case I think it would be worth upgrading server2.example.com, just for the sake of preloading the entire domain name. The issue is that preloading (or using includeSubDomains on the bare domain name) works as a defence against some cookie attacks. The root cause is the lax cookie specification, allowing injection of cookies from one domain name into another.

Ivan,
server1 and server2 was just a sample. There are many server1 and server2 in our enterprise. For example I am responsible for several server1 in our company, but there are server2 types of servers in many different countries whole different teams responsible for it. It is not so simple to migrate.

Also including into https preloading is not instant. When preload info is inserted into official web page https://hstspreload.appspot.com/ then it can take several months before preloading is in effect in browsers, because new https preloading definitions are applied when new browser versions get released.
Regards

Please give us a test page and some time to ensure our settings continue to receive A+ *before* you go live with these changes.
It’s very annoying when things change, and some smartypants customer notices before we do and gives us abuse for not getting A+ !

Because my site has a strong need to be properly secure.
I too use SSLLabs reports to ridicule other insecure web sites myself – heaps of people do this, and indeed, this is the entire purpose of this site – to use “name and shame” and public ridicule to encourage web sites to adopt best-practice.

As the author of SSL Labs, I strongly disagree with your statement that it exists to shame web sites into improving. I built it to help everybody understand their own security. Although it can no doubt be used for naming and shaming, on balance, I think the self-help aspect is more valuable.

Hi Alex – this is great! (I didn’t know it existed) – but we will still need some kind of notice period, and there is no visible versioning system on the dev server: we have no idea which (if any) dev version might be made the live one eventually, or when, or what differences might exist etc – so it will still be a good idea to give users wishing to maintain A+ a more formal way to ensure they remain this rating after the upgrade!

Might I suggest one new feature? Allow us to enter our email addresses when we test our server – this then gives you the opportunity to send notice to any sites who’ve used this feature in future (such as, for example, sending us prior warnings if you detect our rating will change when you next introduce features!. This also means we don’t have to “cron” automated lookups which force your site to re-test our servers every day :-)

HTTPS redirected to HTTP: I see no point of having supper secure https site, but every request is redirected to http. It is just not secure. Grade F should be appropriate grade.

Additionally, I also noticed there are sites having https with HSTS which is excellent, but using http without redirecting to https. In this case now you can get A+ grade, but most of the people writing only domain name in browser address bar will never get any security. Don’t know what should be more appropriate grade, but A+ seem not good one, maybe B or C would be better.

Additionally, there are some sites where https with no HSTS gets A+, but they also have the same http site without redirecting to https. In this case it may be that http site and https sites do not have the same content, so it would be little bit unfair to grade such a site too low. But in my humble opinion having http and https with different content is bad practice and should be somehow graded to not have A+.

There are also sites with passive mixed content. I currently do not remember if this influences on grading or not, but if e.g. image is transferred using clear text it is obvious this is not really secure. I know this is little bit difficult to test, because on main web page ssllabs is testing can have zero passive mixed content, but some subsite may have. Don’t know how we should rate this, or rate it at all. But sites like this are not secure.

You make some really good points and I will try to incorporate most of them into the grading criteria. I think the problem is that SSL Labs originally started as a way of just-testing port 443 configuration. Now it’s probably a good idea take both ports 80 and 443 as a whole into consideration.

There is NO POINT using SSLLabs to work out how good your SSL configuration is, when you subject all your customers to MitM and downgrade attacks by not configuring your web server to properly bootstrap TLS in the first place. “A+” is a nice start, but heaps of sites are cheating this score by running their A+ machine on a different subnet, and customers cannot reach that machine without first arriving via insecure HTTP.

People use this service to see if they are secure. You have a responsibility to educate them that for as long as they’re serving back HTTP content, none of their customers are secure, no matter what their TLS rating might say.

I don’t think ssllabs have any responsibility, because they are offering free service.

In my humble opinion it all depends on the ssllabs mission. Like I see it now the ssllabs mission is to check SSL/TLS of web server in order to help web server administrators to correctly configure security. But what Chris and I would also like to see is change of mission to: “make sure end-user accessing web site really gets secure access”. In this case also checking port 80 for redirecting to correct https server is must.

Chris, why do you think *.domain.tld should never score A+ if domain.tld doesn’t? In my humble opinion this two web pages can have completely different content and why securing one should affect other? In my humble opinion http and https of the same domain should have something in common.

Regarding the 3-DES requirement: As far as I’m aware this is not configurable in most mainstream software, because it’s usually not possible to set different cipher strings for different TLS versions. (E.g. I see no way to configure apache like that.)

That would practically mean a hard deprecation of 3-DES for many sites. It’s a good question if one wants this. From what I’m aware the main compatibility target of 3-DES is Windows XP (which also lacks SNI and SHA-2).

We’ll update the grade as we start implementing the changes. Even though we announced all the changes in one blog post, chances are that we will implement them in two batches. The first batch will cover 3DES and maybe some smaller changes (e.g., fixing the fact that DES is not treated as insecure) and SHA1 deprecation. The second batch will be everything else.

We use T for sites that are not publicly trusted. For example a site that uses a self-signed certificate will get a T. We show the full grade below in small letters, where we ignore the trust problem and “pretend” the site has a publicly trusted certificate.

T grade is tricky. It can mean everything is perfectly fine, because web site uses self-signed certificate. But if using for example bank web site for end-users this grade can reflect something is terribly wrong, like MiTM attack. Because main purpose (mission) of ssllabs is to advice web server administrators, administrators can easily know which one of the option is.

Maybe what ssllabs test could improve is to add some info like on grade mouse hover to display some info or like in case of something is wrong with certificate, to add some link to additionally explain T grade. People are lazy and don’t like to read whole documentation to get quick info.

The TLS 1.3 requirement is going to be a tough one; it never made it in any format to OpenSSL 1.1.0 in any form, and 1.1.0 is not even actively deployed in common Linux distros.
Also, does anybody have a proper cipher line to enable 3DES only on TLS 1.0?

We should wait for TLS v1.3 first to get out of draft. Then two things must happen:
a) web servers should support official protocol version and not draft,
b) major web browsers (Chrome, Firefox, Edge, Safari, Opera…) should support official protocol version.

I know Linux distributions may take some time to implement the newest version, specially because TLS 1.3 is not going to be included in existing versions of OpenSSL, but some time I think it is fair ssllabs starts penalizing servers removing + from A grade.

Currently with no “Forward Secrecy” server gets A-. What does the title really mean? Getting B. To reduce confusion maybe change title from “Forward secrecy required for A” to “Penalty to not using Forward Secrecy (B)”, to be compatible with first title.

@Chris,
you do realize that the year is *2016* and most secure traffic received now is TLS 1.2 for all but the oldest browser?
And like I said new sites that use credit cards cannot have TLS 1.0 on there at all.
And by *2018* (which is implied when this will be next looked at) I imagine the majority of commerce sites that are https will not have TLS 1.0

Sure the test needs to consider usability but it is also (probably surprisingly to you) about security and I think the question is a valid one. Personally I am not sure a A+ rating should be valid for TLS 1.0 sites through to 2018.

As the DROWN attack has shown it is important to penalize the use of old protocol versions, so I really support the changes foreseen in the grading of SSL Labs. On the other hand the DROWN attack has shown other thing as well, such as that the SSL/TLS vulnerability is not limited to the exclusive use of HTTPS protocol. It can be cross-exploited using SMTP -STARTTLS, IMAPS or POPS and so on, since all rely SSL/TLS inside them.

I appreciate so much the work of SSL Labs, I visit this site regularly and frequently to test my web servers. On the other hand I am not only maintaining websites, but e-mail servers as well.
I am testing my mail servers TLS capability with “openssl s_client -starttls smtp” command, but it is very basic testing, I would rather say it is a primitive way.

Do you have any plan to implement testing of other TLS implementations than used in only the world wide web? With other words are you concerned about the TLS security in the use of HTTPS protocols exclusively or inside other protocols like SMTP with STARTTLS as well?

Since the SSL Labs grading change, I noticed that SSL Labs says my webserver doesn’t support TLS_FALLBACK_SCSV. It did say so before. I use the Hiawatha webserver which uses mbed TLS. mbed TLS has SCSV support. Can you tell me what’s going on?

You could, for example, clone your existing server/configuration, run SSL Labs against that and compare the result with that of the original web site. There isn’t an automated way to do it, if that’s what you’re asking.