Este TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 vulnerabil la atacurile Zombie POODLE/GOLDENDOODLE?

Primesc rapoarte mixte despre acesta. Am o gazdă web și mai multe instrumente de scanare SSL (inclusiv cel condus de Laboratoarele Qualsys SSL), spunând că suita de criptare TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 NU este vulnerabil la Zombie POODLE/GOLDENDOODLE și, în același timp, am o firmă de conformitate PCI care indică faptul că este vulnerabil. Din păcate, totuși, niciunul nu este dispuși să cedeze în această chestiune sau să ofere mult mai multe detalii decât ceea ce am menționat deja aici.

Nu știu prea multe despre cripto, dar știu destule că a avea „CBC” doar în numele suitei de cifrare sugerează că implementează înlănțuirea blocurilor de cifră și, prin extensie, înseamnă că are potențialul de a dezvălui din neatenție un oracol de umplutură. , și este astfel vulnerabil la atacurile Zombie POODLE. Dacă acesta este cazul, atunci de ce toate instrumentele de scanare SSL pe care le-am folosit sugerează altfel?

De asemenea, îmi dau seama că există argumente valide împotriva utilizării TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 în general, dar asta nu face obiectul acestei întrebări, deoarece mă preocupă doar dacă este sau nu vulnerabil la atacurile Zombie POODLE/GOLDENDOODLE în mod specific.

Suita de criptare indică faptul că PKCS#7 padded CBC este utilizat cu o verificare MAC efectuată numai după decriptare. Asta înseamnă că este vulnerabil la oracolele text clar înainte de verificarea MAC.

Unpadding este în principal expusă riscului, nu pentru că oracolele de umplutură sunt mai susceptibile de a scurge informații în comparație cu alte oracole de text simplu, ci pur și simplu pentru că dezintegrarea ar avea loc în mod normal înainte ca MAC să fie recuperat.

Trucul de implementare este să nu deblocați în mod explicit, deoarece lungimea textului simplu este cunoscută dinainte și să efectuați o comparație (de preferință constantă de timp) a etichetei de autentificare create HMAC înainte de a utiliza oricare dintre octeții de text simplu.

Dacă implementarea este necunoscută, atunci firma de conformitate PCI are dreptate, introduce un risc. Este unul care poate fi evitat relativ ușor utilizând TLS 1.3 sau TLS 1.2 folosind modul de operare GCM sau CCM pentru AES.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 este un protocol (un subset al familiei de protocoale TLS). Zombie POODLE și GOLDENDOODLE sunt vulnerabilități în unele implementări ale acestui protocol. Deci, dacă firma de conformitate pretinde, știind doar că serverul dvs. acceptă această suită de criptare, că serverul dvs. poate fi vulnerabil la aceste atacuri, sunt corecte. Dacă firma de conformitate susține că, de îndată ce serverul dvs. acceptă această suită de criptare, este vulnerabil la aceste atacuri, atunci se înșelează.

Aceste atacuri se bazează pe o analiză a răspunsurilor de eroare trimise de un server TLS atunci când acesta primește o intrare greșită (care poate proveni de la un client rău intenționat sau de la un om-in-the-middle. (Această analiză include și absența potențială a unui răspuns). ca moment al răspunsului.) Ambele sunt umplutura atacurilor oracolului. Toate suitele de criptare TLS care folosesc CBC sunt vulnerabile la atacurile de umplutură oracle dacă sunt implementate naiv. Aproape fiecare implementare TLS a fost vulnerabilă Lucky Thirteen când a fost dezvăluit în 2013, iar unele pot fi încă vulnerabile la variante ale acestuia, dar OpenSSL și alte câteva stive majore TLS implementează acum contramăsuri care protejează pe deplin împotriva atacurilor de oracle, dacă sunt implementate corect.Aceste contramăsuri sunt intrinsec lente și subtile, așa că este posibil să nu doriți să vă bazați pe ele, dar pentru nivelul de securitate așteptat pentru conformitatea PCI, sunt suficiente.

Dacă serverul dvs. utilizează OpenSSL sau stiva TLS Windows sau majoritatea implementărilor TLS majore, este sigur. (OpenSSL a fost vulnerabil la un alt atac similar descoperit în același timp, denumit „OpenSSL de lungime 0”, deoarece era foarte specific comportamentului OpenSSL.) Ceea ce trebuie să vă faceți în principal este să vă faceți griji sunt niște casete intermediare care decriptează traficul TLS ( firewall-uri, echilibrare de încărcare, â¦). Chiar și așa, atâta timp cât aplicați toate patch-uri de securitate, ar trebui să fiți bine (și dacă cel mai recent firmware este încă vulnerabil, abandonați imediat furnizorul).

În orice caz, puteți utiliza scannerul pus la dispoziție de cercetătorii care au descoperit atacurile pentru a vă testa sistemele. Acesta este același scaner pe care Qualys (și, fără îndoială, alții) îl utilizează, așa că dacă Qualys spune că sistemul tău nu este vulnerabil, nu ai o problemă de securitate: singura ta problemă este să-ți convingi auditorul.

Dacă auditorul dumneavoastră este aproape competent, ar trebui fie să ruleze acest scaner, fie să folosească un serviciu care rulează acest scaner și să concluzioneze că sistemul dumneavoastră nu este vulnerabil. Dar judecând după răspunsul lor, ei pot fi mai puțin decât competenți. Un auditor bun ar fi știut și ar fi putut explica tot ce am scris aici. De asemenea, este ciudat că auditorul menționează doar acele două atacuri împotriva suitelor de criptare bazate pe CBC și nu asupra unora mai vechi precum BEAST, Lucky Thirteen etc.

Cât de mult vă pasă de suportarea suitelor de criptare CBC? Deși pot fi implementate în siguranță, acest lucru necesită ca toate serverele și cutiile intermediare care interceptează TLS să fie de înaltă calitate și să vină cu o penalizare de performanță. Dacă nu nevoie le recomand dezactivarea. În general, pentru TLS, un echilibru bun între securitate și compatibilitate este utilizarea doar a suitelor de criptare bazate pe semnătură (de ex.cu ECDHE sau eventual DHE în numele lor, pe lângă RSA sau ECDSA), cu AEAD (CCM, GCM sau CHACHA20_POLY1305). Unele alte suite de criptare pot fi sigure, dar au un risc crescut de vulnerabilități de implementare.

Deci strategia mea cu acest auditor ar fi:

1. Verificați dacă doriți cu adevărat suite de criptare CBC. Dacă nu, dezactivează-le și spune-i auditorului că acest punct este discutabil.
2. Dacă aveți nevoie de suite de criptare CBC, amintiți-i auditorului că acestea sunt vulnerabilități de implementare și argumentați că Qualys spune că implementarea este vulnerabilă. Dacă încă nu sunt convinși, rulați singur scanerul de oracole de umplutură și invitați-vă și auditorul să facă acest lucru.
3. Dacă auditorul într-adevăr nu va auzi nimic, s-ar putea să nu ai de ales decât să schimbi auditorii. În acest moment, ne-am îndepărtat mult de criptografie și ne-am îndreptat spre domeniul afacerilor.