Mini-thread: Congratulations to @eyalr0, @yuvalyarom, and @cryptodavidw on finding more cache attacks against TLS implementations. It's at http://cat.eyalro.net/ ! This is incredible boundary-pushing work that really goes deep and clearly took a lot of effort!
-
Show this thread
-
For AWS customers: you don't need to do anything and AWS services have not been impacted by this issue. For cryptography people who are interested in the Amazon s2n related parts of this paper, follow on ...
1 reply 2 retweets 5 likesShow this thread -
So basically this issue is a variant of Bleichenbacher's attack on RSA because of how PKCS #1 v1.5 padding works. The original attack works remotely over the network, and eventually recovers a private key by manipulating public RSA input.
2 replies 2 retweets 7 likesShow this thread -
This new issue a variant that uses micro-architectural (CPU-level) issues, so the attacker needs to be on the same machine. The impacted code-bases have secret-dependent branches in their code, and if an attacker can access the came CPU cache, then they can follow the branches.
1 reply 1 retweet 4 likesShow this thread -
For connections that do not use forward secrecy or resumption (which for interest is about 0.08% of connections we see, though that doesn't matter) TLS session keys are established by clients sending a secret to the server encrypted under RSA. This is the vulnerable path.
1 reply 5 retweets 9 likesShow this thread -
Actually, the original Bleichenbacher attack recovers the plaintext, not the key, sorry! But there's also a related attack than can be used to forge signatures.
2 replies 1 retweet 2 likesShow this thread -
Anyway, back to details! So in s2n, we do the SSL/TLS parts, but not the underlying crypto. We support OpenSSL, BoringSSL, LibreSSL and Apple's low level crypto libraries for doing the operations. In this path, basically we call OpenSSL/BoringSSL/LibreSSL's rsa_decrypt()
1 reply 1 retweet 3 likesShow this thread -
That's where "most" of the problem is, because internally the rsa_decrypt() function has branches. We also have a branch outside of it to detect errors, we're not convinced that branch on its own would be sufficient, we lean towards "no".
1 reply 1 retweet 3 likesShow this thread -
Later today, we'll merge a patch that Bryan Donlan from our cryptography team wrote to use a more "raw" RSA mode and so do all of the padding ourselves in s2n. So it'll work around the underlying API. Also credit to
@davidben__ , who suggested this before!2 replies 1 retweet 5 likesShow this thread
We also have a patch for OpenSSL that adds a new mode that's safe by default, but it's an API change. Anyway, that's it really :)
-
-
-
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.