SSL Labs: Increased Penalty When TLS 1.2 Is Not Supported

Ivan Ristic

Last updated on: December 23, 2022

Earlier this week we released SSL Labs 1.17.10, whose main purpose was to increase the penalty when RC4 is used with modern protocols (i.e., TLS 1.1 and TLS 1.2). We had announced this change some time ago, and then put in place on May 20. The same release introduced another change, which was to increase the penalty for servers that don’t support TLS 1.2 from B to C. And it seems that this second change is being somewhat controversial, with many asking us to better explain why we did that.

Although what initially prompted us to think about changing the grading for not supporting TLS 1.2 was grade harmonisation (ensuring that a wide range of servers all get grades that make sense — in other words, to have better-configured servers have better grades), that doesn’t change the fact that the reality is that TLS 1.0 is an obsolete security protocol. TLS 1.0 came out in 1999, followed by TLS 1.1 in 2003 and TLS 1.2 in 2008. These new protocol versions were released for a reason — to address security issues with earlier protocol versions. But, despite being obsolete, TLS 1.0 continues to be the best supported protocol version on many servers. It’s not very bad, mind you — we know from SSL Pulse that about 60% of servers already support TLS 1.2. Client-side, the situation is probably better, because modern browsers have supported TLS 1.2 since 2013. You could say that, overall server configuration is the weaker link.

In that light, we feel that the increase of the penalty for the lack of TLS 1.2 is the natural next step in the deprecation of TLS 1.0. In fact, SSL Labs is probably late in doing that. Just last month, the PCI Security Council deprecated SSL v3 and TLS 1.0 for commercial transactions. No new systems are allowed to use TLS 1.0 for credit card processing and existing systems must immediately begin to transition to better protocols. In comparison, the SSL Labs change of grading is only a mild nudge in the right direction. And, while some people are not happy that we’re pushing for TLS 1.2, others are complaining that we’re not doing enough. For example, the Chrome browser has been warning about lack of TLS 1.2 and authenticated (GCM) suites for some time now. Clearly, it’s difficult to make everyone happy.

The bottom line is that TLS 1.0 is insecure and we must migrate away from it. In 2011, there came the BEAST attack, and, in 2013, the Lucky 13 attack. TLS 1.0 remains vulnerable to this problems, but TLS 1.2 (with authenticated suites) isn’t. These attacks are serious and some organisations continue to use RC4 in combination with TLS 1.0 just to be sure that they are mitigated. We understand that many organisations face significant challenges adding support TLS 1.2, but that is unavoidable. In computer technology, and in security in particular, it is often necessary to keep running just to stay in place.

We did get one thing wrong, however — we didn’t communicate our grading changes in advance. It was not our intention to surprise anyone. In fact, we’d prefer much more if changes were smoother. To that end, in the future we’ll be announcing all grading changes with at least one month notice, and hopefully more for some more significant changes.

Update June 3, 2015: Notification of SSL Labs grading changes (including signups to get notifications by email) is now available at SSL Labs Notifications.

Show Comments (8)


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

  1. I have seen this a lot, many administrators are convinced setting a server an running it for years without a change is good thing to do. For stability it may be, but for security definitely not. In security there is very much alive a Red Queen hypothesis [1]: Running is required to keep in the same place.

    Please don’t be discouraged to set a plan of downgrading bad configured servers. Probably the best way of doing it is like in RC4, to have a announcement strategy when some vulnerability is going to get penalized and explaining why.


  2. Our PCI Auditor, CompliancePoint, said that PCI 3.1 deprecated all protocols less than TLS 1.2. That includes 1.1 that you mention is still acceptable. Do you have any documentation on TLS 1.1 still being valid?

    1. Andy, your auditor should give justification for not allowing TLS 1.1. PCI Council’s document that came out with PCI DSS v3.1 says: "[…]  it is therefore strongly recommended that POI environments use TLS v1.1 or greater wherever possible." You can read it for yourself here:

      Also, SSL Labs doesn’t endorse PCI DSS standards. We have our own criteria and the use of TLS 1.1 is currently not penalised. This version is not as good as TLS 1.2 (e.g., doesn’t support AEAD/GCM suites), but it’s not obviously flawed otherwise.

      1. TLS 1.1 is also limited to using MD5+SHA-1 for ServerKeyExchange signatures  and deriving keys from the premaster secret. neither of these are currently known to be usable for practical attacks, but they do weaken the security of the connection to somewhere below the widely recommended 128-bit minimum.

  3. RFC 7525 states:

    o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246];
    the only exception is when no higher version is available in the
    o Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346];
    the only exception is when no higher version is available in the
    o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
    negotiate TLS version 1.2 over earlier versions of TLS.

  4. Given the current situation with browsers showing warning messages, I think a server that only supports TLS 1.0 as its best protocol should get an F.

  5. I’m trying to disable tls1.2 and enable tls1.3 only. This downgraded my rating from A+ to A. we do not have a requirement to support tls1.2. could you please share if this downgrading is valid as my configuration is still secured.