SSL Labs Grade Change for TLS 1.0 and TLS 1.1 Protocols
Last updated on: December 16, 2022
Update 1/31/2020: The grade change is now live on www.ssllabs.com. Servers that support TLS 1.0 or TLS 1.1 are capped to B grade.
Update 1/16/2020: The grade change is now live on the development server at dev.ssllabs.com. Servers that support TLS 1.0 or TLS 1.1 are capped to B grade on the development server. Deployment to production SSL Labs servers is planned for the very end of January.
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.
Free Trial
Assess, Manage, Detect, and Respond with Qualys VMDR
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 2020January 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 2020January 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
- Modernizing TLS connections in Microsoft Edge and Internet Explorer 11 : https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/
- Removing Old Versions of TLS : https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/
- Deprecation of Legacy TLS 1.0 and 1.1 Versions: https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/
- Modernizing Transport Security: https://security.googleblog.com/2018/10/modernizing-transport-security.html
- Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS): https://tools.ietf.org/html/rfc7525
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.
We are going to cover that removal of TLS_FALLBACK_SCSV when we update blog for TLS 1.3.
Regards,
Yash K.S
Thanks!
What’s the timeframe for this?
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.
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
@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.
Wondering what method is used to determine TLSv1.0 support. The test seems to be falsely reporting TLSv1.0 is enabled.
https://www.ssllabs.com/ssltest/analyze.html?d=ssltest.mywayorelse.net
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.
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
I agree. I think it’s not good to disable old TLS at this point on servers. Browsers are a different thing. It’s good that browsers are avoiding insecure protocols. Servers should be the ones that will follow. Not the other way around.
A correction: Chrome seems to be removing it in March, not in January.
https://security.googleblog.com/2018/10/modernizing-transport-security.html says:
> TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.
Here I believe “early release” means “beta” (though I’m not familiar with the precise terminology they use). Chrome 80 is the release scheduled for January; 81 is scheduled for March.
Why are sites not penalized if they only support weak cipher suites? Today I saw a report of a site that got an A+ although only supporting weak cipher suites.
I agree with some other commentators that getting an A+ should be harder (e.g. requiring CAA, HSTS Preloading, TLS 1.3)
Because of this, many old devices will soon stop loading many sites! And not everyone has the opportunity to buy a new device! Thanks so much for disconnecting!
Hi, I am getting the following:
This server supports TLS 1.0 and TLS 1.1. Grade capped to B. MORE INFO »
My setting is pretty simple:
SSLProtocol TLSv1.2 TLSv1.3
Why does it still think I’m using 1.0 or 1.1 ?
Hello Ted,
Can you post your tested hostname?
I have the same problem. Grade capped to B due to older TLS support. Here are the test results: https://www.ssllabs.com/ssltest/analyze.html?d=devdungeon.dougsilva.me
The virtual host configuration for devdungeon.dougsilva.me is:
SSLProtocol all -TLSv1 -TLSv1.1
I got it working now.
As I’m running the Apache web server and configuring Let’s Encrypt certificates with Certbot, all I had to do was edit /etc/letsencrypt/options-ssl-apache.conf and set the SSLProtocol to:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
A comment in that file explains that, if you want to tweak the options in it, Certbot will no longer update the file automatically when its package updates. However, you will be notified when there are changes so you can apply them manually at your discretion.
I still wonder why some fellows prefer to leave TLS 1.1 on along with modern TLS1.2 and newer.
Is there ANY reason to still have a compromisable door open on a server ? A potential security hole ?
Surely not.
TLS 1.1 does NOT offer strong encryption at all. There are still inherited issues. So, if anyone connects to a https commercial or banking or business website being only capable of using old TLS, this is self-crippling, self-compromising, deliberately self-sacrifiying to “certain grades of insecurity”. And a sign of a VERY old device indeed what he/she is still using. (Android 2.3.7 to 3.x or some windows XP with its native browser or very old iPhones e.g.). For the server-side, the PCIDSS 3.2 talks a clear speech : Offer strong encryption. Only. No compromises. So: Do NO longer even allow anyone to connect to your commercial/business/banking server with security-crippled or -incompatible clients. Avoidance is not a thing of passivity. So be active. Consequent. Doors locked for old TLS (and for inadequate ciphers) means having a sense and also a need for active security measures being in place. Anything else means putting your site’s reputation at risk and leaving it open to a certain degree of compromisability. Sooner or later. This would keep me from sleeping very well.