Announcing SSL Labs Grading Changes for 2017
Last updated on: October 21, 2021
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+
https://www.ssllabs.com/ssltest/analyze.html?d=members2.psprs.com
56-bit DES should be labeled as insecure.
Yes, it should be. It’s an omission that it isn’t already. But it’s also exactly what we announced in this blog post!
Hello,
Why this rule: “HSTS preloading required for A+”? HSTS preloading is just useless.
To get A+, you should require a domain to be protected with DNSSEC and DANE.
Best Regards.
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+ !
Agreed, please give us a test page prior to official changes please.
Wow do you have a lot of customer giving an abuse for not being A+ in sslLabs ? It’s not really fair.
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.
Instead of shaming… I contact my bank and wrote detailed recommendations what could be improved on the bank’s web page, they kindly reply to me and fix security problems.
You could use https://dev.ssllabs.com/ssltest/ for your purpose, I guess.
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 :-)
Downgrade sites for HTTP forwarding to plaintext.
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.
If we go crazy, there is also latent mixed content problem that also gets grade A+. What is this? You have https web site that sends http links inside web site. But when end-user clicks on the link like http://www.youtube.com/some_info then “some_info” string is revealed. Yes youtube will redirect http to https, but the string was already revealed and so can be used for monitoring. I know this is more http scanning then ssl/tls and would require to check the links inside web page etc. It can get complicated… More info on this topic: https://textslashplain.com/2016/03/17/seek-and-destroy-non-secure-references-using-the-moartls-analyzer/
Sometimes it is difficult to say what is the main purpose of ssllabs.com test, should it only test https or some additional http traffic like HSTS http headears, something else inside http to track?
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.
It is time to levy heavier penalties on sites that support HTTP.
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.e. *.domain.tld should NEVER score A+ unless domain.tld does TOO.
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.
MozRepl is a great tool: you can “drive” a real firefox browser from code to monitor what pages really are loading and doing
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).
“Sites that continue to support 3DES and keep it at the end of their ordered list of suites will not be affected.”, so you are OK if you order your ciphers correctly.
IE8 in Windows XP lacks SNI, but it does support SHA2.
Chrome/Chromium and Firefox supports SNI on Windows XP.
No, not really. For as long you prioritise your suites correctly and 3DES is at the bottom, your grade will be fine.
Are there any plans to update the ‘Server Rating Guide’ documentation (https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide.pdf ) to reflect these changes? The last update appears to be 14 October 2015
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.
What Does a Grade of T Mean??
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?
try this TLS configuration generator:
https://mozilla.github.io/server-side-tls/ssl-config-generator/
more info here:
https://wiki.mozilla.org/Security/Server_Side_TLS
and source code here:
https://github.com/mozilla/server-side-tls
That would be because TLS 1.3 is still a draft (and the wire format is still changing). Obviously, they aren’t going to require it for A+ until it’s finalized.
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.
“Forward secrecy required for A”
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.
Also… at the bottom where plan is made (points) there is no “Forward Secrecy” listed, looks like this point was by mistake not included in list.
The items in the last section are separate and in addition to the changes discussed in the remainder of the post; I’ve now reworded the paragraph to make that more clear.
It looks like I have misunderstood last part of the article. Now after you have reworded paragraph I have reread it and it is now perfectly clear. Thanks a lot of clearing this up. Excellent.
Done. Thanks!
Is it time to consider having TLS 1.0 a penalty?
As I am sure you are aware PCI DSS is clamping down on this (new sites and (now) June 2018 for existing sites) and it generally regarded as not as secure as higher TLS’s
As you say this is often a yearly review do you intend to have sites that have TLS 1.0 have the very highest rating A+ until 2018?
@John – you do realize that a *web site* still needs to *work* for visitors, right?
@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?
Hi,
Some of the sites getting A grade even though certificates expired. Can this be changed ?
I don’t think that’s the case. Do you have any examples?
Can you please present the grading logic as a semi-formal flowchart, pseudo-code or open-source code so that it’s independently verifiable for correctness?
Yes, I will (although not for the next minor update but for the bigger one after that). The current format really is difficult to follow.
Hello Ivan, is the grading logic available now ?
No, not yet, although the draft is in a good shape! :)
I’d add HPKP as requirement for A+, too. Rogue and/or incompetent CAs still happen around.
I believe that along side these also dnssec, should be tested since that is a part of security as a hole.
I also agree what is said with Tls 1.3. It is still in draft and should be given amonth or two to settle in prior to requiring it for grading.
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?
Hi Hugo, I opened a ticket to investigate: https://github.com/ssllabs/ssllabs-scan/issues/460 Thanks!
Will there be any API updates to support this ? I see that the last update was on Sep 2016.
You’re looking at the stable branch, which is not updated any more. These days new features are added to the master branch: https://github.com/ssllabs/ssllabs-scan/tree/master
How can we produce a list of which browsers and devices would no longer be supported if we move to an A or A+ rating?
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.