Bleichenbacher demonstrated a padding oracle attack against RSA implementations that follow the PKCS #1 v1.5. Through the years, there are various mitigation techniques developed as OAEP and limiting the number of the query execution over a period of time. OAEP has been proven secure in the random oracle model.

Recently, Ronen et. al demonstrated in The 9 Lives of Bleichenbacher’s CAT: New Cache ATtacks on TLS Implementations that Bleichenbacher is still applicable.

  • How does the new attack work in top level?
  • Which TLS implementations are affected?
  • How one can mitigate from the attack?
  • How does the new attack work in top level?

Even over the years, numerous mitigation techniques are deployed, they showed that some implementations are still vulnerable to various microarchitectural side channels.

They used BEAST-like Man in the Browser attack by using Cache-like attacks to perform a downgrade attack against any TLS connection to a vulnerable server. With this, they showed the feasibility of using those Cache-like attacks.

Although the timeout of the browser limits the attack, they were able to parallelize the attack by using TLS servers that share the same public key certificate.

The attacker requires 3 capabilities:

  1. Side channel capability: attacker must be able to execute code on the victim machine to mount microarchitectural side channel attack
  2. Privileged Network Position Capability: The attacker must be in the man-in-the middle position so that padding oracle attack with the private key can be exploited.
  3. Decryption Capability: The attacker needs an ability to start decryption of ciphertext chosen by him on the target system.

A concrete scenario of the attack:

  • A physical device shared between a TLS server and the attacker's virtual machine. This requires a determined adversary.
  • Second and third can be achieved by the controlling a node between the server and client.
  • Which TLS implementations are affected?

They tested the following implementations:

  • OpenSSL
  • Amazon s2n
  • MbedTLS
  • Apple CoreTLS
  • Mozilla NSS
  • WolfSSL
  • GnuTLS
  • BearSSL
  • BoringSSL

All, except the BearSSL and BoringSSL are affected by their attack.

  • How one can mitigate from the attack?
  • The backward compatibility is the main issue of this attack. TLS 1.3 security doesn't help you if your server can be downgraded to an earlier version.
  • Deprecate the RSA key-exchange.
  • Certificate Separation: Don't use the same key for singing and RSA-key exchange.
  • Constant-Time Code and Safe API as in BearSLL and BoringSSL API.
  • Using Large RSA Keys. The attack requires $\approx \log N$ oracle calls. Use larger keys $>2048$-bits to make the attack less practical.
  • Reduce the TLS Handshake Timeouts in order to make MitM attack harder.
  • Use BearSSL or BoringSSL

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.