Grading of SSL Labs: TLS 1.3 etc...

[McKinleyGroup]

Websites which activate TLS 1.0 and TLS 1.1 can still get away with Grade A. That's very misleading!

• an active TLS 1.3 should result in an A++ grade, if anything else is OK.
• TLS 1.2 should be allowed. TLS 1.2 without TLS 1.3 should result in a grade B.
• an active TLS 1.1 should downgrade a website to C or D
• an active TLS 1.0 should downgrade a website to F. It was hacked in 2011.

[samiona2]

Filipe, This would seem to be premature. TLS 1.3 28th (and seemingly final) draft was just published on 2018-03-23 (not even a month ago). The latest draft is not yet supported by any browsers. Preliminary 1.3 is supported in Chrome since Dev 2017, in Firefox since Jan 2018 and the latest Edge version (pre-release), but this is not based on the final draft. If your suggestion would be implemented, it would likely mean that mean that 99% of sites would not reach an A level. This would loose the utility of this great tool. While our site does support 1.3, going this far would make this wonderful SSL Labs tool a bragging site for the 0.01% that probably support it now. A++ for 1.3 may make sense, but not the downgrades. I do agree that TLS 1.0 should involve a downgrade, but perhaps to a B or not being able to reach A+. All in all, my feeling is that this should be ignored.

[McKinleyGroup]

Hi samiona2,

If your suggestion would be implemented, it would likely mean that mean that 99% of sites would not reach an A level.

That's true. However, TLS 1.2 was defined in RFC 5246 in August 2008 (that's a decade ago!!!) and the TLS 1,2 ciphers weren't meant to deal with quantum computers. Back then in 2008, quantum computing was not as much on the radar as it is today. We cannot assume technological still stand for a decade. And if we do, we are kidding ourselves!

If you look e.g. at iherb.com

https://www.ssllabs.com/ssltest/analyze.html?d=www.iherb.com&s=104.16.110.36&latest

They get an A+ Grade for using TLS 1.0! That's wrong!!! B would be more honest. After all, TLS 1.0 has been compromised in 2008!!! I would feel dishonest advising anyone to use a cipher we all know has been hacked a DECADE AGO!!! :-(

I do agree that TLS 1.0 should involve a mandatory downgrade

Absolutely, we are on the same page about TLS 1.0 being not fit for an A+... using encryption which is compromised is not a badge of honor, it's a stupidity. After all, all you have to do is to take it out of the supported protocols in the server config. Not that difficult, is it?

Red alert: HTTPS has been hacked There's now a tool that exploits a flaw in SSL and TLS. Will the industry respond fast enough? https://www.infoworld.com/article/2620383/security/red-alert--https-has-been-hacked.html

I do agree that TLS 1.0 should involve a downgrade, but perhaps to a B (...).

IMHO, If the SSL Labs grades are supposed to be meaningful, then we should follow your advice:

I do agree that TLS 1.0 should involve a downgrade, but perhaps to a B!!!

This is indeed a good idea, samiona2!

[samiona2]

My suggestion would be that the penalty for TLS 1.0 go into effect at around the time that PCI is enforcing that TLS 1.0 not be used. That is 2018-06-30. See https://blog.pcisecuritystandards.org/webinar-ssl-and-early-tls-migration-preparing-for-30-june-deadline .

[Razerwire]

I think it's a bit dramatic to penalize sites using TLS 1.0 as long as they support TLS 1.2+ AND TLS_FALLBACK_SCSV which prevents downgrading the connection to a lower protocol.

Besides, there aren't any know attacks for TLS 1.2 so TLS 1.2 is safe and TLS 1.3 has only just been made an official standard.....

[FilipeMartins2018]

Hi Razerwire,

Are You Ready for 30 June 2018? Saying Goodbye to SSL/early TLS:

The PCI Security Standards Council will forbid TLS 1.0 from 30 June 2018... ... after all TLS 1.0 has been hacked in 2011!!! That's nearly seven years ago! :-(

[QUOTE]

INFOWORLD TECH WATCH By Roger A. Grimes, Columnist, InfoWorld | SEP 26, 2011 Red alert: HTTPS has been hacked There's now a tool that exploits a flaw in SSL and TLS. Will the industry respond fast enough?

[UNQUOTE]

---

Next time an exploit happens we will all pretend we didn't know... ... however, excactly because of this the IETF has disabled the following ciphers:

• RC4 Steam Cipher,
• RSA Key Transport,
• SHA-1 Hash Function,
• CBC Mode Ciphers,
• MD5 Algorithm,
• Various Diffie-Hellman groups,
• EXPORT-strength ciphers,
• DES,
• 3DES.

I agree with samiona2 that we should have the penalty for TLS 1.0 go into effect at around the time that PCI is enforcing that TLS 1.0 not be used. That is 2018-06-30. See

---

[QUOTE] https://www.thesslstore.com/blog/tls-1-3-everything-possibly-needed-know/

As the time passes, we all (except Keanu Reeves) lose our powers, and so do the security protocols. TLS 1.2, once considered to be fully secure, is now vulnerable (don’t worry, it’s not that simple). This is down to its older, insecure protocols, ciphers and algorithms. TLS 1.3 eliminates such elements of risk by discontinuing support to obsolete ciphers and algorithms. This includes the following:

• RC4 Steam Cipher,
• RSA Key Transport,
• SHA-1 Hash Function,
• CBC Mode Ciphers,
• MD5 Algorithm,
• Various Diffie-Hellman groups.
• EXPORT-strength ciphers,
• DES,
• 3DES.

[UNQUOTE] Disasters like 3 BILLION Yahoo accounts hacked should never have happened in the first place! It's our reponsibility to make sure the internet is safe!

By the way, the NIST (National Institute of Standards and Technology) agrees only TLS 1.2 and TLS 1.3 are safe!

Please see for yourself:

(DRAFT) NIST Special Publication 800-52, Revision 2

Guidelines for the Selection, Configuration, and Use of TransportLayer Security (TLS) Implementations by Kerry McKay & David Cooper

The NIST says:

3.1 Protocol Version Support (page 8 in the PDF)

"Servers that support government-only applications shall be configured to use TLS 1.2, and should be configured to use TLS 1.3. These servers should not be configured to use TLS 1.1, and shall not use TLS 1.0, SSL 3.0, or SSL 2.0."

---

That's very clear, in order to ensure security only TLS 1.2 and TLS 1.3 should be deployed! The use of TLS 1.1, 1.0, SSL 2, and SSL3 is FORBIDDEN!!! That's as plain vanilla as it gets!

[Razerwire]

@FilipeMartins2018 I stand by my earlier statement, TLS 1.2 as a protocol is still very much secure, especially when using it with AEAD Cipher and strong FS.

You're reference to NIST Special Publication 800-52, Revision 2, section 3.1 is targeted at goverment-only applications which means:

A government-only application is an application where the intended users are exclusively government employees or contractors working on behalf of the government. This includes applications that are accessed on a government employee’s bring-your-own-device (BYOD) system. This is in contrast to applications that are publicly accessible.

Qualys SSLabs scans publicly accessible websites so i'm not seeing you're point here either.

[McKinleyGroup]

I agree FilipeMartins2018 given the clear guidance of the NIST:

"Servers that support government-only applications shall be configured to use TLS 1.2, and should be configured to use TLS 1.3. These servers should not be configured to use TLS 1.1, and shall not use TLS 1.0, SSL 3.0, or SSL 2.0."

Now my initial suggestions makes even more sense! The NIST says basically that only TLS 1.2 and TLS 1.3 are safe, and that "TLS 1.0, SSL 3.0, or SSL 2.0." shall not be used and the Qualys SSL Labs test should reflect that!

and

TheSSLStore says basically the same:

TLS 1.2, once considered to be fully secure, is now vulnerable (don’t worry, it’s not that simple). This is down to its older, insecure protocols, ciphers and algorithms. TLS 1.3 eliminates such elements of risk by discontinuing support to obsolete ciphers and algorithms.

TheSSLStore goes even further, because they say " TLS 1.2, once considered to be fully secure, is now vulnerable and TLS 1.3 eliminates such elements of risk by discontinuing support to obsolete ciphers and algorithms.

I agree with @FilipeMartins2018 that we should NOT wait for the next big Yahoo-style mega disaster!

It's time to act now!

[Razerwire]

@McKinleyGroup So in essence "Filipe Pereira Martins McKinleyGroup " agrees with "FilipeMartins2018" so mr. Martins is using two accounts to get his 'point' across.

Again, TLS 1.2 as a protocol is perfectly safe when configured correctly and again mr. Martins you are referring at a Draft standard about Government-only Servers the Section 3.1 is not about publicly accessible websites.

[McKinleyGroup]

@Razerwire

You are contradicting yourself by stating "secure AEAD" and "TLS 1.2".... this DOES NOT make any sense! Correct is: "secure AEAD" and "TLS 1.3"!!!

Secure AEAD ciphers in TLS 1.3 and 1-RTT instead of 2-RTTs and 0-RTT instead of 1-RTT was the whole idea of TLS 1.3!!!

I stand by my earlier statement, TLS 1.2 as a protocol is still very much secure, especially when using it with AEAD Cipher and strong FS.

Only the strong ciphers made it into TLS 1.3,, the weak ones (from TLS 1.2) got pruned in TLS 1.3 and remained in TLS 1.2 ... strong AEAD ciphers are an TLS 1.3-only feature!!!

Read up on the differences between TLS 1.2 and TLS 1.3

Source: WolfSSL Differences between TLS 1.2 and TLS 1.3 June 15, 2017

TLS 1.3

This protocol was defined in an Internet Draft in April of 2017. TLS 1.3 contains improved security and speed. The major differences include:

• The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.

[McKinleyGroup]

Hi @Razerwire

you are referring at a Draft standard about Government-only Servers the Section 3.1 is not about publicly accessible websites.

So the Yahoo disaster with 3 billion email accounts hacked wasn't enough?

Yahoo says all three billion accounts hacked in 2013 data theft https://www.reuters.com/article/us-yahoo-cyber/yahoo-says-all-three-billion-accounts-hacked-in-2013-data-theft-idUSKCN1C82O1

That's what you say? And, it was "ONLY" Yahoo... affected. What if Amazon, Apple, Ebay, Mastercard, Paypal, VISA were impacted too??? That would cause an enormous stock market crash... :-(

Whatever applies to the government's definition of security should ALSO apply to stock market traded companies, shouldn't it? Of course it should! Nobody wants to lose money while selling or buying on the internet!

What if encryption gets hacked when you shop on e-commerce websites and use payment providers? Of course the government needs to be secure, but so do normal users...

The only logical reason to be against TLS 1.3 is if you can't offer TLS 1.3 because it's still in development like e.g. on Windows 10 and Windows Server, but that's a cheap argument to make!!! :-)

[Razerwire]

@McKinleyGroup

The only logical reason to be against TLS 1.3 is if you can't offer TLS 1.3 because it's still in development like e.g. on Windows 10 and Windows Server, but that's a cheap argument to make!!! :-)

I NEVER wrote that i was against (implementing) TLS 1.3 quite the contrary is true.

But the changes you are proposing are - with all due respect - quite preposterous.

[injust]

@FilipeMartins2018 @McKinleyGroup

1. The Yahoo breach, as far as I am aware, was a spear phishing attack that had nothing to do with TLS. The entire point is irrelevant to this discussion.
2. The cipher suites in TLS 1.3 are also not proved to be sufficiently strong against attacks using quantum computing.
3. TLS 1.2 offers secure AEAD cipher suites as well. Just because they also offer non-AEAD cipher suites does not mean that the protocol itself is weak. It is up to the server to select the appropriate cipher suites for negotiation.
4. TLS 1.3 is not even standardized yet, it is still a Proposed Standard. Similarly, OpenSSL builds that support TLS 1.3 are alpha-quality and meant for testing only.
5. The government's definition of security should not also apply to stock market-traded companies. The NIST and PCI guidelines are just that—guidelines, and so are the results produced by SSL Labs.
6. TLS, as well as every other form of security, will constantly continue to evolve. It is impossible to stay on the bleeding edge of every protocol and cipher suite if you want to support your typical client base.

Assuming a properly configured server that prefers stronger cipher suites and protocols over weaker ones, supporting legacy cipher suites and protocols does not decrease the security of modern clients. Modern clients will continue to use TLS 1.2 or 1.3 and negotiate a secure AEAD cipher suite, regardless of your choice to support weak cipher suites, such as DES, for legacy purposes. There is absolutely no problem with having an A+ rating on SSL Labs if you decide to support legacy clients.

[McKinleyGroup]

1. The Yahoo breach, as far as I am aware, was a spear phishing attack that had nothing to do with TLS. The entire point is irrelevant to this discussion.

The discussion in the IC suggests that the hackers used everything at theirs disposal... TLS weaknesses and bugs (of data in transit) & also weak points (of data at rest) in the server config, like no X-XSS headers... :-(

2. The cipher suites in TLS 1.3 are also not proved to be sufficiently strong against attacks using quantum computing.

Yes, cipher suites strong enough to beat quantum computing, like e.g. Supersingular-isogeny Diffie-Hellman (SIDH), are a work in progress. Good point.

However, the argument is mood, because quantum-resistant ciphers will be TLS-1.3-only... ... so staying with TLS 1.2 is pointless, because this standard is history and won't improve anymore!

3. TLS 1.2 offers secure AEAD cipher suites as well. Just because they also offer non-AEAD cipher suites does not mean that the protocol itself is weak.

While this is true, it's besides the point. The IETF cancelled at his latest meeting (in London) all insecure ciphers and ALL SECURE ciphers with INSECURE (!) implementations, such as CBC...

It is up to the server to select the appropriate cipher suites for negotiation. Nice try. However, for the IETF that approach isn't good enough. Only practical results matter...

TLS 1.3 is not even standardized yet, it is still a Proposed Standard.

Wrong!!! – TLS 1.3 is approved: Here's how it could make the entire internet safer The IETF has finally given the okay to the TLS 1.3 protocol, which will speed up secure connections and make snooping harder for attackers:

---QUOTE---

• TLS 1.3 has been approved for use, which will make all secure internet connections faster and safer.
• The security and speed improvements brought by TLS 1.3 are due to the elimination of unnecessary handshake steps and the forced use of newer encryption methods. ---UNQUOTE

That was a MONTH AGO... somehow you missed that!!!

OpenSSL builds that support TLS 1.3 are alpha-quality

OpenSSL 1.1.1 was sponsered by Akamai (according to Rich Salz) and the quality is truly excellent.... runs at Cloudflare, Akamai,... and we use it too! :-)

By the way, OpenSSL 1.1.1 with TLS 1.3 support is officially Beta 3, not Alpha... :-)

The government's definition of security should not also apply to stock market-traded companies.

Let me guess: You want to hack stock market-traded companies?

If you don't want to hack them, then there should be no difference between government agencies and stock-market traded companies... after all it matters if they are secure or insecure!!!

If they are insecure they also fall into the GDPR trap:

I agree with Prof Bill Buchanan OBE, PhD, FBCS that the GDPR is another incentive to keep companies, especially stock market traded ones, as safe as possible:

TLS 1.3 starts a new road-map ... this time it's on a Quantum Path

Assuming a properly configured server that prefers stronger cipher suites and protocols over weaker ones,

That assumption is invalid. otherwise the IETF wouldn't have cleaned out so many ciphers, which in theory are secure. However "secure ciphers" with "insecure implementations" are useless... that's why the IETF made a huge spring cleaning with TLS 1.3 (March 2018)... after all TLS 1.2 goes back a decade to 2008...

Nothing stands still for a decade... Yahoo, Symantec (breach of the IRS database), the Office of Personnel Management (OPM), ... etc. tried this assumption that things only change slowly and that cyber security isn't that important and failed miserably...

Prof Bill Buchanan OBE, PhD, FBCS says: "(...)In the future we must thus encrypt by default, and check of our connections for their identity and trustworthiness. But what happens if the Internet is cracked by a powerful computer? (...)"

And I agree with him! You missed the final TLS 1.3 (final draft 28) by a WHOLE MONTH.... where have you been? Under a proverbial rock?

Read up, before you write funny things...

[injust]

However, the argument is mood, because quantum-resistant ciphers will be TLS-1.3-only... ... so staying with TLS 1.2 is pointless, because this standard is history and won't improve anymore!

So do you advise dropping support for TLS 1.2 right now? Because it's a decade old, and won't be updated anymore? Why not move to TLS 1.3 right now? Who cares about client support?

While this is true, it's besides the point. The IETF cancelled at his latest meeting (in London) all insecure ciphers and ALL SECURE ciphers with INSECURE (!) implementations, such as CBC...

The fact that a newer protocol version eliminates insecure cipher suites doesn't mean that the older protocol is weak. You could always just disable said insecure cipher suites...

Wrong!!! – TLS 1.3 is approved: Here's how it could make the entire internet safer The IETF has finally given the okay to the TLS 1.3 protocol, which will speed up secure connections and make snooping harder for attackers:

You're only partially correct. TLS 1.3 is currently a Proposed Standard. Sure, it's already being used, but until it's standardized in an RFC, it's still a draft, however finalized it may be.

By the way, OpenSSL 1.1.1 with TLS 1.3 support is officially Beta 3, not Alpha... :-)

Apologies, I missed the fact that it moved from alpha to beta. Regardless, if you read the release notes, you may see this: Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes.

And I agree with him! You missed the final TLS 1.3 (final draft 28) by a WHOLE MONTH.... where have you been? Under a proverbial rock? Read up, before you write funny things...

We're discussing TLS protocols here, personal attacks unnecessary. However, if you would like to go that route, your corporate site seems to be lacking some of the security aspects that you are so adamant about. Especially given that your TLS configuration supports the CBC cipher suites that you insist are so insecure, as well as the fact that the entire site is written in Flash.

This is getting off topic, and further discussion would be best continued off this thread.

[McKinleyGroup]

HI @injust

So do you advise dropping support for TLS 1.2 right now?

No, I don't.

Because it's a decade old, and won't be updated anymore?

Yes, it bothers me to use something which is NOT safe...

Why not move to TLS 1.3 right now? Who cares about client support?

Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes.

I read it... but do you think using TLS 1.0 and TLS 1.1 is safe? 99% of all website SSL/TLS configs I've seen so far seem to use it. Do you know that you can decrypt all TLS 1.0, TLS 1.1 and most TLS 1.2 traffic in real-time, intercept it and re-encrypt it? How do you feel about it?

security critical purposes.

In my definition of "security critical purposes" TLS 1.0, TLS 1.1 and most TLS 1.2 traffic don't meet this criterium, because you can decrypt it in real-time, intercept it – even modify it – and re-encrypt... Is this safe?

We're discussing TLS protocols here

Do you deploy TLS 1.3 (even if only on a test domain)? Have you compiled OpenSSL 1.1.1? Which gcc do you use? 4.8.5, 7, or 8? Do you use Nginx or Apache?

Do you use SELinux? Do you use website security headers? Do you use CentOS, RHEL, Fedora (or something else) and if so which version? Did you try ACME 2.0 (wild cards with Let's Encrypt). Which Linux Kernel do you use 2.6.x, 3.x, 4.x or 4.16.x?

This is getting off topic, and further discussion would be best continued off this thread.

Cool, so let's stay on topic. :-)

P.S.: Which website is yours?

P.P.S.: I like HTTPS Everywhere :-) https://github.com/injust/https-everywhere

[injust]

Yes, it bothers me to use something which is NOT safe...

Security can't be defined as safe and not safe, secure and insecure. It's never quite as black and white. In particular, for TLS, the challenge is always keeping a balance between client support and being secure enough.

I read it... but do you think using TLS 1.0 and TLS 1.1 is safe? 99% of all website SSL/TLS configs I've seen so far seem to use it.

Is this surprising? Servers are very rarely updated to the bleeding edge, and many will be stuck using aging protocols.

In my definition of "security critical purposes" TLS 1.0, TLS 1.1 and most TLS 1.2 traffic don't meet this criterium, because you can decrypt it in real-time, intercept it – even modify it – and re-encrypt... Is this safe?

You make it sound like child's play. That's not how MITM works...

Do you deploy TLS 1.3 (even if only on a test domain)? Have you compiled OpenSSL 1.1.1? Which gcc do you use? 4.8.5, 7, or 8? Do you use Nginx or Apache?

I've had TLS 1.3 deployed for benchmarking a while ago, but otherwise no. Haven't bothered to update my patches because the pre-releases drop too often. Also, Clang and nginx are my go-to's. Latest Arch with a hardened version of the latest kernel, always.

Do you use website security headers?

My setup had an A+ configuration a long time before that site rolled out...

Did you try ACME 2.0 (wild cards with Let's Encrypt).

Used to be on Let's Encrypt, abandoned them because I needed wildcard support. Will be migrating back soonTM though.

P.S.: Which website is yours?

In development, shh...

[robmoss2k]

This "issue" violates the "Read This First" Policy:

https://community.qualys.com/docs/DOC-5077

Github is not the place to attempt to influence grading changes.

[FilipeMartins2018]

@Razerwire

I stand by my earlier statement, TLS 1.2 as a protocol is still very much secure, especially when using it with AEAD Cipher and strong FS.

In TLS 1.2 you can downgrade a protocol... in TLS 1.3 you CANNOT downgrade (and also not upgrade a protocol). The idea of IETF is to avoid security breaches.... like BEAST, CRIME, ... ROBOT etc.

TLS 1.2 as a protocol is still very much secure

IMHO, the fact that you can downgrade a protocol in TLS 1.2, makes it less secure... wouldn't you agree @Razerwire ? :-)

[FilipeMartins2018]

Ivan Ristic (Qualys SSL Labs) wrote: https://blog.ivanristic.com/2013/09/is-beast-still-a-threat.html ---QUOTE--- By the way, supporting TLS 1.1 and 1.2 does not actually address BEAST now or in the near future, even though these protocols do not have the predictable IV weakness that's exploited by the attack. The first problem is that most of the Internet still relies on TLS 1.0. Only about 18% of the servers tracked in SSL Pulse support TLS 1.2 today. Thus, even though the next generation of web browsers will all support TLS 1.2, it's going to take a while until the servers are upgraded.

But there is also the second issue, which is that all major browsers are susceptible to protocol downgrade attacks; an active MITM can simulate failure conditions and force all browsers to back off from attempting to negotiate TLS 1.2, making them fall back all the way down to SSL 3. At that point, the predictable IV design is again a problem. Until the protocol downgrade weakness is fixed, newer protocols are going to be useful only against passive attackers, but not against the active ones. ---UNQUOTE---

Especially this matters:

"But there is also the second issue, which is that all major browsers are susceptible to protocol downgrade attacks; an active MITM can simulate failure conditions and force all browsers to back off from attempting to negotiate TLS 1.2, making them fall back all the way down to SSL 3. At that point, the predictable IV design is again a problem. Until the protocol downgrade weakness is fixed, newer protocols are going to be useful only against passive attackers, but not against the active ones."

and this has been fixed in TLS 1.3. The protocol downgrade is blocked in TLS 1.3!

I agree with Ivan Ristic, this downgrade in TLS 1.2 is a severe design flaw!

[Neustradamus]

Any news about TLS 1.3...?

[ArchangeGabriel]

@Neustradamus News regarding what exactly? Support by SSLLabs? Then it is currently supported in the dev instance. It’s inclusion in the grade? For now, it’s only listed as experimental. Grading will likely not change very soon, TLS 1.3 has only been final for two months, and most software stack aren’t yet updated.

[McKinleyGroup]

@ArchangeGabriel @Neustradamus

"News regarding what exactly? Support by SSLLabs?" – Well, it actually works! Qualys SSL Labs says:

Experimental: This server supports TLS 1.3 (RFC 8446).

I hope this helps. :-)

[julian-alarcon]

I think that this can be reviewed again. And set A++ to tls1.3 only version.

[dreamwraith]

TLS 1.3 is widely supported by practically every mainstream web client. downgrading for lack of TLS 1.2 support in 2021 is regressive and absurd.

[Neustradamus]

It is better to have:

• TLS 1.3 in Green
• TLS 1.2 in Orange

It will be the best point to allow server admins (and projects) to add TLS 1.3 compatibility.