Mini-thread: Congratulations to @eyalr0, @yuvalyarom, and @cryptodavidw on finding more cache attacks against TLS implementations. It's at cat.eyalro.net ! This is incredible boundary-pushing work that really goes deep and clearly took a lot of effort!
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 ...
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.
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.
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.
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.
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()
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".
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!
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 :)
