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

41–50 of 69 posts

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

#41

Post by tialaramex »

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…

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 mistake are discovered you'll be vulnerable and won't have a greenfield any more. You get to learn basically the same lessons about agility everybody else did, the same way everybody else learned them. Brilliant.

The Web is not a greenfield development. Google may have "pushed HTTP 2" but you can still connect to their sites using HTTP 1.1 because _of course you can_. So that first step, where you throw everything that already exists away, is immediately the end of your whole strategy for the Web or more or less any public Internet service.

You might be thinking. "OK, old crap stuff would be affected, but my new shiny things would be fine". And you're almost right. But you have to really operate a scorched earth policy, the new shiny things _must not_ interoperate with the old crap at all. And that's a deal breaker in practice on the Internet. If you say "Well, if we can't do shiny I guess we'll do the old thing" then you lose immediately, that's the thrust of their TLS 1.3 example, both client and server want to talk TLS 1.3 which isn't vulnerable - but the attacker abuses the fact that they're willing to talk TLS 1.2 instead.

If you don't want to do RSA kex in your own system where you control all servers and clients, don't do RSA kex. I commend this, it's good sense. You can use the exact OpenSSL version described as vulnerable in this article, switch off RSA key exchange entirely at both ends and the vulnerability vanishes. But alas even "almighty" Google does not control all servers and clients on the Web.

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

#43

Post by esnard »

Flowdalic wrote: post #26
axaxs wrote: post #12

Just commenting since I saw and recognized the name next to BearSSL... Thomas Pornin is an absolute treasure, and anyone interested in entry level crypto and beyond should read through his StackOverflow responses. Many of the answers simplify complex topics into more digestable pieces.

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

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

#44

Post by AstralStorm »

kccqzy wrote: post #33
AstralStorm wrote: post #25

Earlier quoted context omitted.

Why? You should be able to mathematically prove lack of timing channels instead over whole negotiation... (For a specific CPU implementation or a set of them at least.) It's just that even encryption library authors are not mathy enough and it takes effort to model CPUs enough. PKCS#1 RSA is likely possible to be proven broken by design...

And with Intel releasing new micro-architectures all the time invalidating your proof?

Which is why you should use RISC-V Ariane instead which is already being timing modelled by ETH.

Or work on the ARM Cortex M5 verification then run it on AMD-SP which is one. Presuming they allow you to run your own code. Likewise Intel ME... But that processor is some weird architecture.

Or other external hardware - smart card or the fancy U2F.

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

#45

Post by detaro »

AstralStorm wrote: post #44
kccqzy wrote: post #33

Earlier quoted context omitted.

And with Intel releasing new micro-architectures all the time invalidating your proof?

Which is why you should use RISC-V Ariane instead which is already being timing modelled by ETH. Or work on the ARM Cortex M5 verification then run it on AMD-SP which is one. Presuming they allow you to run your own code. Likewise Intel ME... But that processor is some weird architecture. Or other external hardware - smart card or the fancy U2F.

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

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

#46

Post by tialaramex »

merb wrote: post #37
tialaramex wrote: post #19

Earlier quoted context omitted.

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…

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.

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

#47

Post by _null_ »

tialaramex wrote: post #22
kccqzy wrote: post #21

Why is using RSA for key exchanges acceptable? I thought we had dedicated key exchange algorithms, Diffie–Hellman (DH), the ephemeral variant (DHE), and the elliptic curve variant (ECDHE). So why RSA? Also, what if I disable RSA in my browser and make sure the ClientHello doesn't mention RSA? Will I be secure?

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?

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

#48

Post by AstralStorm »

detaro wrote: post #45
AstralStorm wrote: post #44

Earlier quoted context omitted.

Which is why you should use RISC-V Ariane instead which is already being timing modelled by ETH. Or work on the ARM Cortex M5 verification then run it on AMD-SP which is one. Presuming they allow you to run your own code. Likewise Intel ME... But that processor is some weird architecture. Or other external hardware - smart card or the fancy U2F.

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 other RISC-V in order cores. Proving out of order execution is hairier, a lot of work to be done.

Oh, and you get to freeze the code to given validated compilation FIPS style. Any random C compiler revision can mess you up. Or rerun the prover.

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

#49

Post by devit »

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 that's enough to break anything unless you can remotely cause the peer to hit slow disks or make network requests depending on secret data (which is a far more explicit programming choice than CPU timing differences).

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

#50

Post by pedrocr »

tialaramex wrote: post #41
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…

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 idea. There has to be a limit somewhere to that tradeoff. At some point starting fresh allows you to throw away enough crap that you come out ahead.

> If you say "Well, if we can't do shiny I guess we'll do the old thing" then you lose immediately, that's the thrust of their TLS 1.3 example, both client and server want to talk TLS 1.3 which isn't vulnerable - but the attacker abuses the fact that they're willing to talk TLS 1.2 instead.

There is no difference there between changing from 1.2 to 1.3 and from 1.2 to ShinyNewStuff. My point is that from what I've read we've learned enough that we could design something better than TLS if we started fresh, so we could do TLS1.2->ShinyNewStuff instead of TLS1.2->TLS1.3 and get some advantages. The downgrade attacks are present in both cases until you eventually discontinue 1.2.

>If you don't want to do RSA kex in your own system where you control all servers and clients, don't do RSA kex.

One of the things we've learned over the last 25 years is that having optionally insecure ways to use security standards is a very bad idea. So the fact that configuring TLS well enough is feasible is part of the problem, not the solution. That's the kind of thing we could potentially fix.

Post reply on HN