Mă pot gândi doar la o slăbiciune a AES-CBC în TLS 1.1 și mai sus, care este Atacul Lucky Thirteen. Acesta este un atac asupra unei modalități prost concepute de a tampona mesajele care îl face deosebit de vulnerabil la a padding oracol atac datorită utilizării MAC-apoi-criptare (cu o schemă de umplutură care face atacul destul de ușor).
Atacul original s-a bazat pe obținerea unui decryption_failed alertă când umplutura a fost greșită, ceea ce a fost fixat în TLS 1.1 continuând cu o cheie de sesiune aleatorie pentru o eroare de umplere (și implementările TLS 1.0 au aplicat și această contramăsuri). Cu toate acestea, implementările naive ale TLS 1.2 continuă să fie vulnerabile la acest atac prin sincronizare: ceea ce trebuie să știe atacatorul este câți octeți de umplutură sunt corecti, iar timpul necesar procesării mesajului scurge aceste informații, cu excepția cazului în care implementatorul a fost foarte atent. .
Versiunile moderne ale implementărilor TLS mainstream protejează împotriva Lucky Thirteen, astfel încât, în general, puteți utiliza în siguranță suitele de criptare CBC. Cu toate acestea, această contramăsuri are un cost de performanță: implementarea trebuie să fie procesată toate posibile lungimi de umplutură, dintre care există până la 256, și apoi combinați rezultatele. Atenție că implementările mai vechi sau implementările care nu sunt concepute pentru securitate ridicată pot fi încă vulnerabile.
Unele implementări TLS (cel puțin OpenSSL, GnuTLS și Mbed TLS) acceptă extensia criptare-apoi-MAC care protejează complet împotriva acestei vulnerabilități.
În orice caz, singurul motiv pentru utilizare Suitele de criptare CBC sunt de a vorbi cu sisteme vechi care nu acceptă suitele de criptare AEAD (folosind GCM, CCM sau Chacha-Poly). Suitele de criptare AEAD sunt mai rapide și mai puțin predispuse la accidente de securitate. De obicei, motivul pentru care suitele de criptare CBC încă există este de dragul sistemelor care au un motor de criptare care este efectiv imposibil de actualizat (de exemplu, deoarece a fost certificat și nimeni nu vrea să plătească pentru a certifica o implementare a GCM sau CCM). Dacă motivul pentru a evita GCM și Chacha-poly este prezența accelerației AES, CCM va profita de acest lucru și va fi de obicei mai rapid decât suitele de criptare CBC (care necesită un calcul HMAC).
Suite de criptare CBC au fost eliminate în TLS 1.3 pentru că sunt greu de implementat corect (și imposibil de implementat atât cu performanță ridicată, cât și cu securitate ridicată) și singurul motiv pentru a le păstra a fost compatibilitatea cu sisteme mai vechi. Cu o versiune de protocol mai nouă, nu exista niciun motiv semnificativ pentru a le păstra. Și pentru că TLS 1.3 și-a propus să excludă toate mecanismele criptografice care sunt greu de implementat în siguranță, suitele de criptare CBC au trebuit cu siguranță să meargă.
