SSL Labs Grading Changes January 2017

Ivan Ristic

Last updated on: October 21, 2021

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. Per the earlier blog post, there will be other changes in 2017. We will talk in more detail about them later on.

Update (3 April 2017): The changes documented in this blog post are now live, in SSL Labs 1.28.3.

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.

SHA1 deprecation

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.

Show Comments (49)


Your email address will not be published. Required fields are marked *

  1. “Sites that continue to support 3DES and keep it at the end of their ordered list of suites will not be affected (for now).”

    That is a mistake. There is zero reason to use 3DES with TLSv1.2 because TLSv1.2 makes support for at least TLS_RSA_WITH_AES_128_CBC_SHA mandatory.

    You should also penalize use of IDEA & SEED ciphersuits with TLSv1.2 for the same reason.

  2. It’s not true to suggest that the SWEET32 attack isn’t practical. It might not be practical in many parts of the world, but if you have a client and server on the same LAN it could take just minutes, and anyone lucky enough to have a 200Mbps internet connection at home (like me) to saturate and a powerful multicore PC could lose an important cookie overnight whilst asleep.

    It’s not practical to attack a mobile phone on 3G, sure, but 3DES is dangerous because there is the potential for hacking a small percentage of Internet users, to whom 785GB isn’t actually that much traffic.

    1. Rob, the Sweet32 authors said “In our proof-of-concept demo, this attack currently takes less than two days, using malicious Javascript to generate traffic.”. So, yes, that’s 758 GB, but not downloading at full speed; the traffic has to be generated by a browser sending about 1,500 connections per second. Those are clearly lab conditions.

    2. Keep in mind though that 3DES encryption is highly CPU intensive, and as such could likely slow down the target server.
      On my own server, according to the openssl speed -evp des-ede3-cbc benchmark I cannot even fill my outgoing network line with 3DES encryption without maxing out my CPU.

  3. Ivan,

    what if we limit the number of requests (either memory or number of connects)? That’s a suggestion by the F5 Support. yawast does such a check.

    I see no possibility to limit ciphers to a certain TLS version.


    1. Peter, I don’t think you need the ability to control cipher suites on per-protocol basis. Everything should work as intended if you place TLS 1.2 suites at the top and make sure that 3DES is at the bottom. Give it a try and please get it touch if you can’t get it working properly.

      1. Ivan,

        I tried the dev-ssllabs and it downgraded our website from A+ to C. 3DES is definitely at the bottom of our cipherlist:

        Cipher Suite Name (RFC)

        Apparently that is not what you expected, right?

        Thank you for your help.


        1. No, in your case the grades are correct. If you look at the “Java 8u31” simulation, toward the bottom, you’ll see that it uses 3DES with TLS 1.2. I’d recommend adding TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA to the top of your cipher suite list. That should do the trick.

          1. Ok, apparently ECDHE+HIGH in our version of the BigIP will result in a ECDHE-3DES.

            We were able to remove that explicitly with :-3DES: .

            Thanks for pointing me in the right direction.

  4. Could it be possible to slightly tweak grading to foster GCM suites? For instance if a server has the cipher suites ordered with CBC in front of GCM lower the grade to A- or B- instead of A/A+ B.

    1. Even it, say, TLS 1.0 isn’t supported, if their cipher suite lists are properly done, 3DES will never be negotiated and we will not apply the penalty. On the other hand, what will happen soon is that all servers offering obsolete crypto will be downgraded to B. If actually used with modern browsers, then C.

    1. We are currently showing future Grade to notify before the actual Grade changes.

      Once New Grades are applied, It will reflect on corresponding Bars and other sections. In this case Certificate bar will be capped to 0.

  5. hi guys,

    I try to use qualys WAS to scan my website and it doesn’t detect this error but when i’m using the ssllas it detect this error

    “This server is vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade set to F.”

  6. Our site grade is F. what to do for a fix?

    Godaddy India does not help us to fix this problem. I have worst experience with them today, more than 1 hours talking no result, there a no email support for customers, lol.

    Could you guys help us in this?


  7. Hi all,

    between Thursday and Friday you have changed the article in a case which does not look professional to me.

    The major change, previously you headlined “Penalty for using 3DES with modern protocols (C)”, now it says “Penalty for using 3DES with TLS 1.2”

    It is understandable that changes can happen but please notify the people that you altered the text and which parts were altered.

    1. SomeGuy, I changed the text but didn’t change the meaning. In the original wording, “modern protocols” meant TLS 1.2. The new heading leaves less to interpretation. In the rating guide the penalty was already defined through TLS 1.2. I also made small wording improvements in other places in response to a prompt via Twitter.

      That said, there is another change that I do want to highlight and I will do it now. Thanks!

      1. Ivan,

        How soon until SSL Labs checks browsers and servers for TLS 1.3? As of recent updates, it is in both of the production versions of Chrome and Firefox. Also, how long until it will be considered insecure (and result in penalization) if a site still supports TLS 1.0 or 1.1 (even if they offer 1.2 and/or 1.3)?


        1. About TLS 1.0, we’re probably going to classify it as legacy in some point in 2018, in anticipation of the PCI deadline. I don’t think we’ll consider such sites insecure (as practical attacks don’t exist, at least not today), but the grade will probably be B.

  8. I am looking at a report for a site that places TLS_RSA_WITH_3DES_EDE_CBC_SHA at the top of the cipher list. However, it only says A- without warning of upcoming penalties to C.

      1. Server is
        Says “Server has no preference” and lists TLS_RSA_WITH_3DES_EDE_CBC_SHA first.
        I didn’t notice that particular line regarding server preference.
        Does having 3DES on newer protocols with no preference not make the site subject to the upcoming grading changes?

        Sorry, I just didn’t want to “name and shame” any website owners, as they had requested an evaluation on at the time.

        1. When we test, we look if 3DES is negotiated with TLS 1.1 or newer protocol; if it’s not then there’s no penalty. If you need to use 3DES then using cipher suite prioritisation is the only sure way of avoiding the penalty, but it can happen even without it, but it’s practically luck.

  9. hello. sorry that not everybody is so super smart concerning all the cryptostuff… :) at the moment i have the following apache 2.2.32 settings (with openssl 1.0.2k) that gives me a A+ with a future C:

    SSLProtocol -ALL +TLSv1.1 +TLSv1.2
    SSLHonorCipherOrder On
    SSLCompression On
    Header always set Strict-Transport-Security “max-age=31556926”

    what is it that i should add or remove to this to keep the A(+), but still provide so much compatibility that we won’t lock out half of the internet users?
    i am very grateful for your insights – and as usual, a complete sample config for the noobs like us is usually the best… :)

  10. Would SSLLabs consider either eliminating Java as a reference browser for the 3DES logic, or assuming that Java has the JCE Unlimited Strength policy files installed and thus Java can negotiate 256 bit AES ciphers? I’m finding a number of sites that prioritise AES-256, then 3DES, then AES-128 which is fine for most browsers, but not Java.

    1. Hi Evan. Probably not. Prioritising 3DES ahead of AES 128 is suboptimal and I don’t think we should make exceptions to hide the problem away. Regarding Java, I can’t say that have any evidence, but I think that most JRE installations don’t support AES 256. Having Java there serves as an important reminder that having only AES256 is not enough.

      Overall, I think this grading update could work well as an opportunity for sites to reevaluate their use of 3DES and at least push it firmly to the bottom.

  11. When the new grade will replace the current parallel old + new grade?
    When is expected the next round of grade changes announced in November 16, 2016?

    Thanks for this useful tool!

  12. Hi,

    Thanks for the heads up on the grading changes. Some questions:

    1) Our site uses 3DES in some shape or form with TLS1.1, but it’s getting an A and no warining about future grade.
    Is this because 3DES is at the end of the ciphersuite preference list?

    2) I found a site that has a current grade of A and a future grade of C.
    However the result page doesn’t state explicitly why it is getting a C. In this case I think the only reason can be the 3DES change.
    Possible nice to have for a future grading change would be to see the exact reason for a grade change.

    3) Is the API capable of returning the future grade?
    When using the GO client, there’s no “futuregrade” field or some other field that looks like it is holding the future grade.
    Not critical, but would be nice to get a headsup if you’re using the API for checking the grade of sites.

    Thanks for all the work,


  13. Hi, and thanks for the recent update.
    I want to let you aware that when using chrome on android when opening the site info (clicking on the lock icon, then details) some sites are shown as having obsolete crypto, while with ssllabs they get an A rating.
    This is somewhat confusing for users. It would be nice if ssllabs could penalise a bit more these sites (B or C rating) in the next update.

  14. My administrator used to get a A rating but after removing CBC other than what is required to support TLS1.2, the rating dropped to A- due to legacy browsers like Safari6 not supporting FS if CBC is diaabled.

    Does it make sense to penalize the rating if legacy browsers cannot negotiate FS without CBC?

  15. After one year treating 3DES as “weak” (though it has been proven vulnerable to facilitated targeted attacks such as the birthday phenomenon, also called the sweet32 flaw) it is time now to increase the penalty for generally accepting it together with TLS 1.2 (on capable clients which are at 99.9% now I think – disregarding built-in browsers on VERY OLD devices and old outdated OSes which still run now unsupported unpatched browsers except ATM/POSmachines on embedded XP as this receives TLS 1.2 as a late implementation) and even for generally offering it on servers which also have TLS 1.2 in operation and therefor would not need it at all.