Timeline for Using AES-CBC in TLS1.2
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 18, 2021 at 19:10 | comment | added | Gilles 'SO- stop being evil' | @dave_thompson_085 OpenSSL started to add support for encrypt-then-MAC in 2013, GnuTLS in 2014, Mbed TLS in 2014. 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). | |
| Oct 18, 2021 at 19:03 | answer | added | Gilles 'SO- stop being evil' | timeline score: 2 | |
| Oct 18, 2021 at 7:35 | comment | added | Maarten Bodewes♦ | @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... | |
| Oct 18, 2021 at 1:04 | comment | added | dave_thompson_085 | (@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). | |
| Oct 17, 2021 at 20:34 | comment | added | Maarten Bodewes♦ | $ $ Yes, that's correct. | |
| Oct 17, 2021 at 15:18 | comment | added | miklo009 | @MaartenBodewes so in general TLS 1.2 still allows to use the default implementation of AES-CBC which is not secure? | |
| Oct 17, 2021 at 14:04 | comment | added | Maarten Bodewes♦ | Those that report PKCS#7 padding exceptions. TLS uses MAC-then-encrypt, so it is vulnerable against padding oracle attacks. | |
| Oct 17, 2021 at 13:48 | comment | added | miklo009 | @MaartenBodewes are there non default implementations specified somewhere? Which part of the default implementation would be vulnerable? | |
| Oct 17, 2021 at 11:34 | comment | added | Maarten Bodewes♦ | In short: it's insecure if you use any default implementation of AES-CBC, which is bad enough to exclude it. | |
| Oct 17, 2021 at 6:17 | review | Close votes | |||
| Nov 3, 2021 at 3:04 | |||||
| Oct 17, 2021 at 5:58 | comment | added | kelalaka | Does this answer your question? Why was AES CBC removed in TLS 1.3? | |
| S Oct 17, 2021 at 0:02 | review | First questions | |||
| Oct 17, 2021 at 17:05 | |||||
| S Oct 17, 2021 at 0:02 | history | asked | miklo009 | CC BY-SA 4.0 |