Using AES-CBC in TLS1.2

Question

Is AES-CBC still vulnerable in TLS1.2 Or does the vulnerability only work for lower TLS versions? If not, why was it deleted in TLS 1.3?

Answer 1

I can only think of one weakness of AES-CBC in TLS 1.1 and above, which is the Lucky Thirteen attack. This is an attack on a poorly designed way to pad messages which makes it particularly vulnerable to a padding oracle attack due to using MAC-then-encrypt (with a padding scheme that makes the attack rather easy).

The original attack relied on getting a decryption_failed alert when the padding was wrong, which was fixed in TLS 1.1 by continuing with a random session key on a padding error (and implementations of TLS 1.0 also applied this countermeasure). However, naive implementations of TLS 1.2 continue to be vulnerable to this attack through timing: what the attacker needs to know is how many bytes of padding are correct, and the time it takes to process the message leaks this information unless the implementer was very careful.

Modern versions of mainstream TLS implementations protect against Lucky Thirteen, so generally you can safely use CBC cipher suites. There is a performance cost to this countermeasure, however: the implementation basically has to process all possible padding lengths, of which there are up to 256, and then combine the results. Beware that older implementations or implementations not designed for high security may still be vulnerable.

Some TLS implementations (at least OpenSSL, GnuTLS and Mbed TLS) support the encrypt-then-MAC extension which completely proctects against this vulnerability.

In any case, the only reason to use CBC cipher suites is to talk to old systems that don't support AEAD cipher suites (using GCM, CCM or Chacha-Poly). AEAD cipher suites are faster and less prone to security mishaps. Typically the reason CBC cipher suites still exist is for the sake of systems that have a cryptography engine that is effectively impossible to upgrade (for example because it's been certified and no one wants to pay to certify an implementation of GCM or CCM). If the reason to avoid GCM and Chacha-poly is the presence of AES acceleration, CCM will take advantage of that and will typically be faster than CBC cipher suites (which require an HMAC calculation).

CBC cipher suites were removed in TLS 1.3 because they're hard to implement correctly (and impossible to implement with both high performance and high security) and the only reason to keep them was compatibility with older systems. With a newer protocol version, there was no significant reason to keep them. And because TLS 1.3 aimed to exclude all cryptographic mechanisms that are hard to implement securely, CBC cipher suites definitely had to go.