SSL Labs Grade Change for TLS 1.0 and TLS 1.1 Protocols

Update 10/11/19: The TLS 1.0/1.1 warning changes are now live on www.ssllabs.com. The grade change for supporting TLS 1.0/1.1 is changed from March 2020 to January 2020 as shown below in the “SSL Labs Grade Change” section below and as reflected in the summary messages in SSL Labs results.

Update 11/30/18: Now live on ssllabs.com: In Configuration->Protocols section “TLS 1.1” text color will be changed to Orange by end of November 2018.

TLS 1.0 and TLS 1.1 protocols will be removed from browsers at the beginning of 2020. As there are no fixes or patches that can adequately fix SSL or deprecated TLS, it is critically important that organizations upgrade to a secure alternative as soon as possible.

Various Browser clients have provided approximate deadlines for disabling TLS 1.0 and TLS 1.1 protocol:

Browser Name Date
Microsoft IE and Edge First half of 2020
Mozilla Firefox March 2020
Safari/Webkit March 2020
Google Chrome January 2020

 

Best practices outlined in RFC-7525 give reasons why it is discouraged to use protocol TLS 1.0 and TLS 1.1. PCI-DSS recommends users to switch from protocol TLS 1.0 and adopt protocol TLS 1.2+.

Following table shows for each browser the percentage of connections made to SSL/TLS servers using protocol TLS 1.0 and TLS 1.1:

Browser/Client Name Percentage (%) – Both TLS 1.1 and TLS 1.0
Microsoft IE and Edge 0.72%
Mozilla Firefox 1.2%
Safari/Webkit 0.36%
Google Chrome 0.5%
SSL Pulse November 2018 5.84%

 

SSL Labs Grade Change

To encourage users to migrate to protocol TLS 1.2+ and remove protocol TLS 1.1 and TLS 1.0 from servers, SSL Labs will lower the grade for SSL/TLS servers which use TLS 1.1 and TLS 1.0.

TLS 1.0 Grade change date:

  • A warning will be displayed for downgrading to grade “B” by end of September 2019
  • Grade will be changed to “B” by end of March 2020 January 2020

TLS 1.1 Grade change date:

  • In Configuration->Protocols section “TLS 1.1” text color will be changed to Orange by end of November 2018
  • A warning will be displayed for downgrading to grade “B” by end of September 2019
  • Grade will be changed to “B” by end of March 2020 January 2020

Existing Grades Sample

Server Configuration Grade
TLS 1.2, TLS 1.1, TLS 1.0 + HSTS + No Warning + TLS_FALLBACK_SCSV A+
TLS 1.2, TLS 1.1, TLS 1.0 + HSTS + No Warning +  No support for TLS_FALLBACK_SCSV A
TLS 1.2, TLS 1.1, TLS 1.0 + HSTS + Warnings + No support for TLS_FALLBACK_SCSV A-

 

Future Grades Sample

Server Configuration Grade
TLS 1.2, TLS 1.1, TLS 1.0 + HSTS + No Warning + TLS_FALLBACK_SCSV B
TLS 1.2, TLS 1.1, TLS 1.0 + HSTS + No Warning +  No support for TLS_FALLBACK_SCSV B
TLS 1.2, TLS 1.1, TLS 1.0 + HSTS + Warnings + No support for TLS_FALLBACK_SCSV B
TLS 1.2 + HSTS + No Warning + TLS_FALLBACK_SCSV A+
TLS 1.2 + HSTS + No Warning + No support for TLS_FALLBACK_SCSV A
TLS 1.2 + HSTS + Warnings + No support for TLS_FALLBACK_SCSV A-

 

References

11 responses to “SSL Labs Grade Change for TLS 1.0 and TLS 1.1 Protocols”

  1. Can the FALLBACK_SCSV requirement be removed? Every SSL library and browser out there has basically completely removed fallbacks, and you mentioned that the requirement for A+ would go away if TLS 1.3 didn’t reintroduce the fallback. It didn’t reintroduce the fallback.

  2. You may also want to update SSL Pulse:
    * TLSv1.1 yellow rather than green (like TLSv1.0);
    * TLSv1.1 and TLSv1.0: green color when negative variation;
    * Key Strength Distribution: remove “Below 2048 bits”;
    * Key Strength Distribution: green color on negative variation of 2048 bits (it’s the minimum accepted);
    * Forward Secrecy: green color on negative variation of everything but “Used with most browser”;
    * Certificate Signature Algorithms: remove SHA1.

  3. I also have recommendations for a future modernized SSLPulse display :
    – Removal of the “SPDY” gauge as there is stagnation/decline at low percentage already, ALPN and NPN are its technologial successors and increasingly coming in use, which would deserve its own stats diagram instead.
    – Text change regarding the “Protocol downgrading protection/TLS_FALLBACK_SCSV support” stats gauge:
    For the grey “unknown” partition being solely stated this is not entirely correct. In fact it rather says “unknown method / not supported or only ONE protocol being active currently (mostly TLS 1.2 only is seen on many modern servers not having a TLS 1.3 capable stack – or there is no ECDSA certificate present on a server which is a minimal prerequisite to support TLS 1.3 even if the stack itself has been updated to support it ! – and some pretty old ones that only support TLS 1.0 while having SSL3 and 2 already disabled – as then there no other protocol can be used either”
    – the colour bars in the result window on server analysis :
    Servers that support insecure suites, anon suites, SSL3/SSL2 when also including ciphersuites for it and also have implicit protocol vulnerabilities present, (Bleichenbacher, Drown, Poodle, other severe-rated CVE vulns e.g.) should have these warning messages shown in signaling RED (with yellow lettering), not in pastelpink, as this is a severe misconfiguration/or obviously and seriously unpatched or default state on a server facing the web from today’s standpoint.
    Not only the red [ F ] rating at the top. But the whole thing. F should really come out and being well understood as saying “The assessed particular server has explicitely FAILED our test and does not even meet minimal requirements for adequate data transport security”, not only as the most bad rating finally.
    Weak DHE handshakes below 2048bit plain or even weaker than 192bit in EC : rates down and warning message in RED “no FS being provided with the given handshake method” behind the detected suite.
    – SHA-1 hashing suites displaying in orange as it is not collision-free.
    Servers not showing HSTS headers should get A- in the future. Since this is such a good precaution to prevent handshakefree session intrusion when it is established, this should become a minimal requirement for a proper A rating once. Everything else detected for weakening it (even with HSTS present) : B

    Kind regards!

    bernd

  4. @yash
    A few comments. Your scan has tremendous influence on the market. A+ should be exactly that – “exceptional configuration” as per SSL Labs documentation. Why not:
    1. have a higher score for HSTS preloading (or restrict A+ to ones that do)?
    2. Restrict A+ for servers that support TLS 1.3 and not 1.0 and 1.1 (thank you for adding the orange color for 1.0 and 1.1)
    3. Penalize for the lack of forward secrecy? As per SSL Pulse, about 20% do not support it, but those probably are penalized already
    4. CAA should be required for A+
    5. Not really security related, but should http/2 support impact things?

    Thank you for what you do for the security of the internet.

    • I am able to connect to that site with TLSv1 with openssl s_client. Try the following command to reproduce and test:

      openssl s_client -tls1 -connect ssltest.mywayorelse.net:443

      Note, at the time of my testing, that domain resolved CNAME a6q3f6e3.stackpathcdn.com and to IP 151.139.128.10.

    • This is because without SNI, SSL Labs is able to connect with TLS 1.0 protocol. In the protocol section, if you hover over the “Yes” word, a title/hint pops up with the details. I’d recommend you to check for other SSL configurations in your server that has TLS 1.0 support.

  5. While I wholeheartedly agree with this change for TLS v1.0, I would not agree with capping TLS v1.1 to a “B” grade this early. There are a lot of providers like ourselves that have to consider overall compatibility with client browsers and while we’ve dropped v1.0 long ago, we’re still supporting v1.1.

    Since you’ve decided to move up the date, would you consider leaving v1.1 for a later date and only capping v1.0?

    • Pete Howell:

      Browser are going to disable/warn both TLS 1.0 and TLS 1.1 on same time, we are mainly going by this decision as explained in blog.

      Regards,
      Yash K.S

Leave a Reply