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

31–40 of 69 posts

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

#31

Post by baybal2 »

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…

RSA is a reliable algo, key exchange protocols are not, and are being broken all the time.

Where is exceeds is its original use in PGP/GPG as no complicated key exchanges are taking place

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

#33

Post by kccqzy »

AstralStorm wrote: post #25
hombre_fatal wrote: post #10

Jesus. Imagine being enough of a genius to actually write timing-safe code.

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?

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

#34

Post by pizzazzaro »

Someone1234 wrote: post #2

> The cat is not dead yet, with two lives remaining thanks to BearSSL (developed by my colleague Thomas Pornin) and Google's BoringSSL. Some kind of award has to go to this sentence, that has to be the most convoluted way to simply say "aren't vulnerable." In context you can only just barely follow it, and it literally involves counting the vulnerable + un-vulnerable libraries to check they all add up to 9...

Yeah... What about LibreSSL?

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

#35

Post by george_perez »

pizzazzaro wrote: post #34
Someone1234 wrote: post #2

> The cat is not dead yet, with two lives remaining thanks to BearSSL (developed by my colleague Thomas Pornin) and Google's BoringSSL. Some kind of award has to go to this sentence, that has to be the most convoluted way to simply say "aren't vulnerable." In context you can only just barely follow it, and it literally involves counting the vulnerable + un-vulnerable libraries to check they all add up to 9...

Yeah... What about LibreSSL?

LibreSSL has no TLS 1.3 support yet.

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

#36

Post by pedrocr »

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 better designed crypto standard in one of those efforts?

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

#37

Post by merb »

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…

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.?

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

#38

Post by opportune »

AstralStorm wrote: post #25
hombre_fatal wrote: post #10

Jesus. Imagine being enough of a genius to actually write timing-safe code.

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...

yeah next time I deploy a web backend lemme figure out if I can implement timing channels in my framework and also make sure the framework authors modelled the encryption suite so that's even possible, it's not like I'm an actual software engineer getting paid to ship features instead of thinking mathematically about the encryption libraries I'm using

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

#39

Post by markonen »

walrus01 wrote: post #11

Downgrading to TLS1.2 isn't the end of the world. One of the things you can do to make a significant difference is configure all of your httpd (apache2, nginx, whatever) to specifically disallow SSLv3, TLS1.0 and TLS1.1. There is no longer any relevant population of useragents that don't understand TLS1.2.

Android only added TLSv1.2 in Android 5.0. Sure, seems that was ages ago, but Android 4.x audiences can still be relevant to some.

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

#40

Post by koolba »

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…

That's a long road. Plus, short of cutting off support for legacy versions you would not mitigate downgrade attacks. On the flip side, if we're ever going to go down that road it needs to start somewhere.

A middle ground might be a modern stripped down TLS stack and something similar to HSTS to externally flag that a given site does not accept downgrades.

Post reply on HN