Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

nccgroup.trust

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

#61

Post by merb »

tialaramex wrote: post #46
merb wrote: post #37

Earlier quoted context omitted.

Actually what I mean is that my server only responds with TLS 1.2, nothing below or above. So I am still vulnerable to 1. and 2.?

Yes. Despite the HN title the article topic isn't really "We found a new problem in TLS 1.3" it's closer to "Bleichenbacher Oracles still exist in lots of TLS implementations, although in two of the nine we checked we couldn't find an Oracle". They only mention TLS 1.3 because otherwise uninformed people would say "Just upgrade to TLS 1.3" which won't fix the problem.

Thanks. Still confusing title, guess best Would be tls 1.2,1.3

Re: Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

#62

Post by tialaramex »

pedrocr wrote: post #59
tialaramex wrote: post #58

Earlier quoted context omitted.

> TLS is 25 years old now. The on-the-wire protocol has some faint resemblance but the actual technology between SSL 2.0 and TLS 1.3 are utterly different. The original Bell phone system where you have to talk to an operator and say "Give me 4235 please", and a modern iPhone, are also utterly different - but every step along the way was achieved by backwards compatibility and that meant some compromises. So the iPhon…

>but every step along the way was achieved by backwards compatibility and that meant some compromises This is not a good analogy. The phone system has thrown away plenty of standards as well. Throwing away TLS for something else doesn't have any compatibility problems on the web. There is no difference in compatibility between doing 1.2->ShinyNew and doing 1.2->1.3. Maybe we can do enough within just TLS versions to…

> Throwing away TLS for something else doesn't have any compatibility problems on the web

No. Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this.

> But for some reason that keeps not happening and insecure options like these still exist.

Unfortunately you don't even understand enough about this topic to have noticed that the article is specifically mentioning a downgrade because the "insecure options like these" do not exist in TLS 1.3.

Insisting that problems you don't understand will go away if we just rewrite everything again from scratch is even closer to CADT than the anti-agility enthusiasts.

Re: Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

#64

Post by pedrocr »

tialaramex wrote: post #62
pedrocr wrote: post #59

Earlier quoted context omitted.

>but every step along the way was achieved by backwards compatibility and that meant some compromises This is not a good analogy. The phone system has thrown away plenty of standards as well. Throwing away TLS for something else doesn't have any compatibility problems on the web. There is no difference in compatibility between doing 1.2->ShinyNew and doing 1.2->1.3. Maybe we can do enough within just TLS versions to…

> Throwing away TLS for something else doesn't have any compatibility problems on the web No. Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this. > But for some reason that keeps not happening and insecure options like these still exist. Unfortunately you don't even understand enough about this topic t…

>Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this.

Those are part of the problem we should be solving. Delaying TLS 1.3 to enable middleboxes is precisely the kinds of things we should be throwing away from any standard. That TLS 1.3 was close enough to 1.2 for broken middleboxes to show how broken they are is an example of how backwards compatibility at all cost bites you, and yet you are using it to claim the opposite.

It's perfectly possible that all that needs to be done for TLS to stop being a continuous problem is a sane TLS 1.4. But I'd like to see an actual argument for what that would look like instead of you just insulting me without adding anything to the discussion.

Re: Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

#65

Post by tialaramex »

pedrocr wrote: post #64
tialaramex wrote: post #62

Earlier quoted context omitted.

> Throwing away TLS for something else doesn't have any compatibility problems on the web No. Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this. > But for some reason that keeps not happening and insecure options like these still exist. Unfortunately you don't even understand enough about this topic t…

>Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this. Those are part of the problem we should be solving. Delaying TLS 1.3 to enable middleboxes is precisely the kinds of things we should be throwing away from any standard. That TLS 1.3 was close enough to 1.2 for broken middleboxes to show how broken t…

> Those are part of the problem we should be solving. Delaying TLS 1.3 to enable middleboxes is precisely the kinds of things we should be throwing away from any standard.

Your "solution" of just breaking things while declaring this "doesn't have any compatibility problems" is not a solution people are going to accept. It genuinely doesn't matter that you think it'd be a great idea, not the tiniest bit, since it would see no adoption.

TLS 1.3 did not take this "backwards compatibility at all cost" approach you describe. On the contrary, it was engineered very carefully to work _around_ middleboxes. The protocol is untidy as a result, with extraneous compatibility fields, but the cryptography remains as intended. But you've not addressed that at all since your entire basis is "From what I've read a lot of the issues is the complexity of the standard itself".

Again, this issue you're reading about today is NOT a problem with TLS 1.3, and would not have been fixed by any changes to TLS 1.3 or imaginary alternatives to TLS 1.3 _unless_ as a side effect they prohibited falling back to earlier versions, something you can already choose to do if that's what you want (you do not).

Re: Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

#66

Post by pedrocr »

tialaramex wrote: post #65
pedrocr wrote: post #64

Earlier quoted context omitted.

>Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this. Those are part of the problem we should be solving. Delaying TLS 1.3 to enable middleboxes is precisely the kinds of things we should be throwing away from any standard. That TLS 1.3 was close enough to 1.2 for broken middleboxes to show how broken t…

> Those are part of the problem we should be solving. Delaying TLS 1.3 to enable middleboxes is precisely the kinds of things we should be throwing away from any standard. Your "solution" of just breaking things while declaring this "doesn't have any compatibility problems" is not a solution people are going to accept. It genuinely doesn't matter that you think it'd be a great idea, not the tiniest bit, since it woul…

>It genuinely doesn't matter that you think it'd be a great idea, not the tiniest bit, since it would see no adoption.

The discussion around TLS 1.3 delays included plenty of people that also thought middleboxes should not be enabled. If a standard that broke compatibility with them completely would be adopted is an open question.

>TLS 1.3 did not take this "backwards compatibility at all cost" approach you describe. On the contrary, it was engineered very carefully to work _around_ middleboxes. The protocol is untidy as a result, with extraneous compatibility fields, but the cryptography remains as intended.

The second part contradicts the first. The standard has had to be made more complex to allow for the backwards compatibility and that's a future liability. We've had other holes in TLS from these extra complexities that are completely unneeded.

>Again, this issue you're reading about today is NOT a problem with TLS 1.3

Again that's not my point at all. I'm not discussing today's issue in particular. I'm referring to the fact that we keep finding bugs in TLS consistently. I was wondering if we were at the point were a clean slate would reduce this. I've made that point, someone else has pointed out to an experiment in doing just that, maybe someday we'll get a full test. You're dismissal of the actual question as if it's invalid is just being unpleasant without being helpful.

Re: Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

#67

Post by loeg »

0xdeadb00f wrote: post #28
throwawaymath wrote: post #8

Earlier quoted context omitted.

Good question. The paper is here[1] but there is no mention of LibreSSL. 1: https://eprint.iacr.org/2018/1173

Strange. LibreSSL a fairly well-known implementation compared to something like BearSSL (which I had not heard of until today). Does anyone have any ideas on why LibreSSL was not mentioned?

It's not really independent. It's a major fork of OpenSSL, but at the end of the day, it's a fork of OpenSSL.

Re: Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

#68

Post by aomix »

wilsonthewhale wrote: post #4

Is LibreSSL affected?

As others have mentioned, TLS 1.3 is not yet supported. But a little bit of context for that decision as of early last year.

https://github.com/libressl-portable/portable/issues/228#iss...

We will support 1.3 once the standard is firmed up and finalized (i.e. ceases to be coopted by vendors making changes to allow for people to continue to run moribund middle boxes that can't recognize a new protocol on the wire) Since there is effectively nothing wrong with TLS 1.2 with a sanely chosen cipher suite today, we believe a clean careful implementation is more beneficial than early adoption.

So there's no rush on the part of the developers to support it. Skimming the commits on that git mirror we can see 1.3 related commits started hitting late last year.

Re: Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries

#69

Post by mwwaters »

inetknght wrote: post #3

> The last 20 years of attacks that have been re-discovering Bleichenbacher's seminal work in 1998 clearly show that it is close to impossible to correclty implement the RSA PKCS#1 v1.5 encryption scheme. While our paper recommends a series of mitigations, it is time for RSA PKCS#1 v1.5 to be deprecated and replaced by more modern schemes like OAEP and ECEIS for asymmetric encryption or Elliptic Curve Diffie-Hellman…

I'm a bit late, but this is referring to ditching RSA only for encrypting a symmetric key. The algorithm is vulnerable to side channel attacks since it expects the plaintext to follow a certain padding. The method only has 6% use today and is generally deprecated for DH.

For DH, RSA is still used purely for signatures. RSA is not used to hide any data.

Post reply on HN