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

51–60 of 69 posts

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

#51

Post by dharmab »

_null_ wrote: post #47
tialaramex wrote: post #22

Earlier quoted context omitted.

Your browser probably doesn't have an option to do this. If it did you'd find out that certain sites just don't work if you forbid RSA key exchange. The type of site that wants SSL Labs A+ scores works fine. But your bank probably doesn't (they actively don't want ephemeral key exchange) and nor does some crumbly older HTTPS site running a stitched together Apache 1.x on an old Debian release. To protect against this…

Serious question: Why does the bank care about the TLS key exchange?

Some businesses have to run WAF products for regulatory compliance, which is typically implemented via TLS decryption at a WAF. There are ways to do TLS decryption with ephemeral keys but many orgs just use the easy way of just giving the WAF the RSA key.

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

#52

Post by detaro »

AstralStorm wrote: post #48
detaro wrote: post #45

Earlier quoted context omitted.

Different RISC-V and ARM cores also have differing timing?

Yes, which is why I mentioned the specific Ariane in-order application processor and specific ARM processor. If the encryption algorithm validates in SeL4 Ariane environment, it is algorithmically side channel free. However, this does not say anything about it being side channel free on x86 Linux - out of order execution, more caches, HT - all Spectre vectors. Of course the proof can be easily extended to handle othe…

Huh, I could have sworn your comment said you should use RISC-V instead. Apologies.

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

#53

Post by pedrocr »

rutthenut wrote: post #18
arto wrote: post #14

Earlier quoted context omitted.

Seconded, and sourced: > Microsoft cited public stats from SSL Labs showing that 94 percent of the Internet's sites have already moved to using TLS 1.2, leaving very few sites on the older standard versions. > "Less than one percent of daily connections in Microsoft Edge are using TLS 1.0 or 1.1," Pflug said, also citing internal stats. https://www.zdnet.com/article/chrome-edge-ie-firefox-and-saf...

Well given the amount of Internet traffic out there, I'd say that one percent (albeit 'less than' that) could be rather a lot of traffic that would be blocked if TLS 1.0 or 1.1 were totally dropped or blocked.

The suggestion was to block it at the server not the browser. Presumably most of that 1% is because of old sites/servers and not old browsers.

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

#54

Post by raesene9 »

esnard wrote: post #43
Flowdalic wrote: post #26

Earlier quoted context omitted.

Link to his stackoverflow answers sorted by votes: https://stackoverflow.com/users/254279/thomas-pornin?tab=ans...

Thomas Pornin actually posted a lot of answers on multiple sites on the StackExchange network, under two different accounts: https://stackexchange.com/users/92852/thomas-pornin https://stackexchange.com/users/969353/tom-leek

It's worth noting that on security.stackexchange.com , The Bear and his alter ego are no.1 and 2 by reputation, respectively.

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

#55

Post by tialaramex »

devit wrote: post #49

How about the obvious solution to all timing attacks of sending a network response after a timer set to 2^K milliseconds expires rather than when the data is ready? (with K adaptively incremented and decremented only rarely, outliers managed by starting the timer again so that the time is rounded up to 2^K) This way, the only timing signal available would be which requests take an outlier amount of time, and I doubt…

The article is about cache side channels. They are running on the same CPU as the victim, typically in the Clown. Your "solution" isn't addressing the problem this article is about.

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

#56

Post by chrisweekly »

tialaramex wrote: post #19
merb wrote: post #17

am I vulnerable if I only use TLS 1.2?

Yes. The only way to be invulnerable to this class of attack is of one of: 1. You never use RSA at all (the attack needs a server to be willing to do RSA decryption, but clients only need to be willing to do RSA for certificate verification) 2. Everything is "on premises". This is a cache timing attack and probably won't be practical even a short distance away over a network. 3. Server doesn't allow any version below…

Thank you; not OP but helpful summary.

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

#57

Post by axaxs »

esnard wrote: post #43
Flowdalic wrote: post #26

Earlier quoted context omitted.

Link to his stackoverflow answers sorted by votes: https://stackoverflow.com/users/254279/thomas-pornin?tab=ans...

Thomas Pornin actually posted a lot of answers on multiple sites on the StackExchange network, under two different accounts: https://stackexchange.com/users/92852/thomas-pornin https://stackexchange.com/users/969353/tom-leek

Thanks for this, StackExchange was actually what I was thinking of when I wrote StackOverflow. Luckily, he also posts there a lot as well. I think my favorite answer is as below, as it's the first time I could recall a simplified answer of how TLS works, while retaining technical detail. A gift for sure...

https://security.stackexchange.com/questions/20803/how-does-...

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

#58

Post by tialaramex »

pedrocr wrote: post #50
tialaramex wrote: post #41

Earlier quoted context omitted.

Sure, this is the standard anti-agility argument. "Oh, we understand yesterday's mistakes now, so, just throw away everything built before today and start fresh, then there will be no mistakes". It's like CADT but with cryptography. If you have the luxury of greenfield development, you are welcome to try this. There's a pretty good chance you'll screw up badly, but regardless when tomorrow more opportunities for mist…

> It's like CADT but with cryptography. TLS is 25 years old now. CADT is not a fair criticism when more than the lifetime of a whole teenager has elapsed. At some point building a second system is worth it. >You get to learn basically the same lessons about agility everybody else did, the same way everybody else learned them. Brilliant. We would also get to throw away a bunch of stuff we already know was a very bad i…

> 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 iPhone still has "phone numbers" even though you probably rarely use them for anything.

That's all that was going on in TLS. The "start fresh" you were originally asking for involves _throwing away_ that compatibility to get "some advantages". I explained why TLS doesn't do that. The feeling that surely starting over would help is _exactly_ CADT even if you're not a teenager.

You absolutely can have those "some advantages" if you don't want backwards compatibility. But it's not obvious why you'd rewrite TLS rather than just use TLS in this case and refuse to downgrade below TLS 1.3. What happens when TLS 1.4 has even more "advantages" ?

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

#59

Post by pedrocr »

tialaramex wrote: post #58
pedrocr wrote: post #50

Earlier quoted context omitted.

> It's like CADT but with cryptography. TLS is 25 years old now. CADT is not a fair criticism when more than the lifetime of a whole teenager has elapsed. At some point building a second system is worth it. >You get to learn basically the same lessons about agility everybody else did, the same way everybody else learned them. Brilliant. We would also get to throw away a bunch of stuff we already know was a very bad i…

> 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 fix the flaws. Maybe doing 1.4 with a much stricter set of conditions is possible and so we should keep the base. But for some reason that keeps not happening and insecure options like these still exist. But the compatibility argument doesn't exist. The end user would not notice anything.

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

#60

Post by baby »

pedrocr wrote: post #36

With the amount of TLS vulnerabilities I don't really understand why we're not just replacing it completely. From what I've read a lot of the issues is the complexity of the standard itself that we could do much better now that so much more is known about good crypto practice. Google has already pushed HTTP 2 and now 3 thanks to having very sizeable chunks of both the browser and the sites. Why not also have a much b…

shameless plug, this is where current research is heading: https://cryptologie.net/article/467/quic-noise-nquic/
Post reply on HN