Profile picture
Colm MacCárthaigh @colmmacc
, 10 tweets, 3 min read Read on Twitter
Mini-thread: Congratulations to @eyalr0, @yuvalyarom, and @cryptodavidw on finding more cache attacks against TLS implementations. It's at ! 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 :)
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Colm MacCárthaigh
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!