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!
-
-
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.
Show 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.
Show 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()
Show 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".
Show 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!Show 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 :)
Show this thread
End of conversation
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.