21–30 of 69 posts
Also, what if I disable RSA in my browser and make sure the ClientHello doesn't mention RSA? Will I be secure?
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?
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 attack the server needs to refuse to try RSA key exchange OR you need to refuse RSA altogether including the safe and extremely popular authentication step.
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.
The article itself is actually only doing TLS 1.3 downgrade in passing, and probably only because if they don't some people will say TLS 1.3 fixes this magically (it couldn't).
It's a Bleichenbacher Oracle, again. So the effect is you get the server to do RSA operations for you. You don't learn their private key, but the server uses it and you eavesdrop on the process.
A TLS 1.3 ONLY server isn't vulnerable (no Oracle) and a client isn't vulnerable even in TLS 1.2 if it refuses to use RSA completely. But unlike your suggestion to disable much older versions, those options aren't very practical today.
Jesus. Imagine being enough of a genius to actually write timing-safe code.
PKCS#1 RSA is likely possible to be proven broken by design...
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.
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…
3. Almost all known servers accept TLS 1.2, and definitely banks.
Is LibreSSL affected?
Good question. The paper is here[1] but there is no mention of LibreSSL. 1: https://eprint.iacr.org/2018/1173
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...
I rest my case.
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...
> It's just that even encryption library authors are not mathy enough I rest my case.
Except someone wrote a library for timing proofs (including cache and memory) in Isabelle/HOL already, but it has to be combined with the recompile prover from SeL4 project. That would take some time and work.