0

In order for a server to be vulnerable to the LUCKY13 exploit, it has to use a ciphersuite which uses CBC and must not use the encrypt_then_mac TLS extension. However, if both these conditions are satisfied, is the server necessarily vulnerable to LUCKY13? Does openSSL mitigate this attack by adding random delays when using CBC mode ?

If that's the case, is there a way to test for certain for the presence of this vulnerability? As far as I know, testssl only returns "Potentially vulnerable" when a server uses CBC without encrypt_then_mac.

Tristan Nemoz
  • 103
  • 3

1 Answers1

2

No, using CBC in TLS without the encrypt-then-MAC extension does not necessarily mean that the implementation is vulnerable. This attack is what we call a padding oracle, in that CBC used in this way requires padding and the attack exposes, through a timing side channel, whether the padding was correct. This is because the MAC is over the plaintext and doesn't prevent the attacker from trying to modify the ciphertext without being immediately detected.

However, it is possible to write constant-time padding verification code, which is what most major TLS libraries have done. Thus, most major implementations are not vulnerable, but you'd need to check the documentation for your version to be sure.

If you use encrypt-then-MAC or an AEAD, then the ciphertext is authenticated, and padding need not be verified in constant time since it's computationally infeasible for an attacker to modify the padding without causing the MAC or authentication code to fail. This is why AEADs are the only option in TLS 1.3 and CBC is not recommended in TLS 1.2 and below.

bk2204
  • 7,828
  • 16
  • 15