2
$\begingroup$

I am building an Apache webserver with TLS 1.2 and OpenSSL 1.0.1. So far, I have enabled 2 encryption algorithms - ECDHE AES-256 GCM and ECHDE AES-128 GCM.

Firefox and Chrome / Chromium use NSS which currently does not support AES-256 GCM, but it works with AES-256 CBC. Because they do not support AES-256 GCM, they fall back to AES-128 GCM.

I would like to enable AES-256 CBC, but I am not sure about the security of it.

This site http://uwnthesis.wordpress.com/2013/06/25/how-to-select-the-safest-encryption-using-aes-gcm-encryption-to-obtain-perfect-forward-secrecy/ states multiple times that CBC is insecure and should not be used.

Is it safer to use AES-128 GCM or AES-256 CBC?

Improve this question
$\endgroup$
3
  • $\begingroup$ SSL made an unfortunate choice when combining AES-CBC with MACs. This means that it's quite hard to implement CBC correctly. It isn't easy to implement GCM in a way that resists timing attacks on a CPU without AES-NI, so it's not perfect either. $\endgroup$
    – CodesInChaos
    Commented Feb 22, 2014 at 19:28
  • $\begingroup$ I wouldn't care too much about key-size. 128 bits is already quite strong. $\endgroup$
    – CodesInChaos
    Commented Feb 22, 2014 at 19:29
  • $\begingroup$ So it's hard to implement correctly. But is the OpenSSL implementation correct? I just want to know whether it is at least as safe as GCM. (Because as far as I know the server is what controls the encryption, so if the server implementation is correct it is safe. Or does it also depend on the client?) $\endgroup$
    – the_pwner224
    Commented Feb 22, 2014 at 19:59

1 Answer 1

Reset to default
0
$\begingroup$

Because AES CBC does not provide authenticated encryption, this leads to many interesting attacks, which allow to modify or guess plaintext. Such attacks as BEAST or Lucky 13 are based on this vulnerability of AES CBC. Some details about this attacks you can find here.

Improve this answer
$\endgroup$
4
  • 2
    $\begingroup$ SSL still provides authentication even with CBC based modes. The real problem is that SSL combines AES-CBC with a MAC in a MAC-then-authenticate scheme, which is pretty hard to implement. Older SSL versions also don't choose unpredictable IVs, which CBC requires. So these problems are not inherent in CBC, they result from the way SSL uses CBC. $\endgroup$
    – CodesInChaos
    Commented Feb 23, 2014 at 9:33
  • $\begingroup$ Yes, you are right. But I think main reason of this problems is that CBC mode allows to influence the plaintext by changing the ciphertext. $\endgroup$
    – neverwalkaloner
    Commented Feb 23, 2014 at 9:57
  • $\begingroup$ "which is pretty hard to implement. Older SSL versions also don't choose unpredictable IVs" So if I use only TLS 1.2 CBC is safe? $\endgroup$
    – the_pwner224
    Commented Feb 23, 2014 at 15:46
  • $\begingroup$ @the_pwner224 I don`t think so. Using unpredictable IV does not protect against timing attacks, as Lucky13. This attack applies to all TLS version. "The attack applies to all implementations that conform to TLS version 1.1 or 1.2, or DTLS version 1.0 or 1.1. It also applies to implementations of SSL 3.0 and TLS 1.0 that have countermeasures designed to defeat a previous padding oracle attack discovered several years ago. All TLS and DTLS ciphersuites that include CBC-mode encryption are potentially vulnerable." From document, which I link in my answer $\endgroup$
    – neverwalkaloner
    Commented Feb 23, 2014 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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