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 ...
-
-
Show 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.
Show 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.
Show 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.
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 -
-
-
Interesting work. Kind of ironic that the page serving the paper is HTTP-only.
-
couldn't find a secure implementation to serve it with HTTPS!
- 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.