Score:0

Using AES-CBC in TLS1.2

us flag

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?

kelalaka avatar
in flag
Does this answer your question? [Why was AES CBC removed in TLS 1.3?](https://crypto.stackexchange.com/questions/52566/why-was-aes-cbc-removed-in-tls-1-3)
Maarten Bodewes avatar
in flag
In short: it's insecure if you use any default implementation of AES-CBC, which is bad enough to exclude it.
us flag
@MaartenBodewes are there non default implementations specified somewhere? Which part of the default implementation would be vulnerable?
Maarten Bodewes avatar
in flag
Those that report PKCS#7 padding exceptions. TLS uses MAC-then-encrypt, so it is vulnerable against padding oracle attacks.
us flag
@MaartenBodewes so in general TLS 1.2 still allows to use the default implementation of AES-CBC which is not secure?
Maarten Bodewes avatar
in flag
$ $ Yes, that's correct.
dave_thompson_085 avatar
cn flag
(@MaartenBodewes) for the 'lucky13' padding oracle, there is an OPTION for encrypt-then-MAC, rfc7366 in 2014, but I'm not aware of any implementation that added EtM without also adding 1.3, which of course is generally preferable. The _other_ vulnerability of CBC in 1.0 and SSL3, exposed-IV, attacked by BEAST (resulting in people for a while switching TO!! RC4), was fixed in 1.1 (and 1.2).
Maarten Bodewes avatar
in flag
@dave_thompson_085 I am mentioning the generic attack against CBC with padding in that protocol. Timing specific attacks are only useful when the padding oracle is not directly available based on error conditions and such. And yeah, I cannot remember seeing EtM anywhere...
Gilles 'SO- stop being evil' avatar
cn flag
@dave_thompson_085 OpenSSL started to add support for encrypt-then-MAC [in 2013](https://github.com/openssl/openssl/commit/5e3ff62c345c976cd1ffbcc5e6042f55264977f5), GnuTLS [in 2014](https://gitlab.com/gnutls/gnutls/-/tree/e93cef18471962b001dac0f792cb569f1a4cde58), Mbed TLS [in 2014](https://github.com/ARMmbed/mbedtls/commit/699cafaea27c72ea68aa85bd8a4e18afb879e272). It's not universally supported, but it's way older than TLS 1.3. It is more recent than TLS 1.2, however, which was the first version to have a good alternative to CBC (GCM).
Score:2
cn flag

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.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.