Grup DH partajat, secrete noi: de ce atacul devine mai ieftin

Parametrii grupului sunt publici prin proiectare, și tocmai această publicitate îi face ușor de ignorat. În Diffie-Hellman peste un corp finit, modulul și generatorul sunt partajate, în timp ce exponenții privați și cheile de sesiune rezultate nu sunt. Etapa scumpă a unui atac cu ciur peste corp de numere depinde de grup și nu de un singur schimb, așa că un singur grup slab folosit peste tot devine o răspundere comună. A numi parametrii publici este exact și în afara subiectului, pentru că costul refolosit este costul atacării acelui grup.

Jumătatea publică nu este jumătatea vulnerabilă, și acolo este capcana

Jumătatea obișnuită de argument spune că parametrii sunt publicați într-un standard, deci un atacator îi știe deja, iar ascunderea lor nu ar schimba nimic. Ambele afirmații sunt adevărate și niciuna nu decurge din cealaltă. Un grup implicit livrat este public, iar un grup privat generat săptămâna trecută este și el vizibil oricui finalizează strângerea de mână. Secretul nu a fost niciodată controlul; puterea și validarea sunt.

Ce se schimbă este câte locuri împart aceeași slăbiciune. O organizație care își generează propriul grup de 2048 de biți plătește propriul cost de atac, în timp ce o valoare implicită de protocol aleasă de milioane amortizează un singur cost asupra tuturor. În acest sens un grup neobișnuit nu este automat mai bun. Un grup neobișnuit care este prea mic este doar un secret comun mai mic, cu mai puțini ochi asupra lui.

Validarea contează la fel de mult ca dimensiunea. Un partener care trimite un modul cu factori mici, sau unul care nu are forma așteptată de protocol, poate scurge informații despre exponentul privat chiar și atunci când lungimea în biți pare respectabilă. Bibliotecile care resping parametrii malformați la intrare fac o muncă reală, motiv pentru care analiza parametrilor scrisă de mână este un loc prost pentru a economisi efort.

Ce îi oferă de fapt precalculul unui atacator

Ciurul peste corp de numere are o etapă care depinde doar de numărul prim, iar rezultatul său este reutilizabil împotriva fiecărui schimb care folosește acel prim. Acesta este întregul mecanism din spatele îngrijorării istorice: partea scumpă se plătește o dată, iar costul marginal al fiecărei sesiuni ulterioare scade. Exponenții noi încă protejează fiecare schimb individual de un observator pasiv, atât timp cât grupul este suficient de mare pentru ca ciurul să fie imposibil. Cele două afirmații sunt compatibile, iar majoritatea dezbaterilor pe această temă provin din alegerea uneia și renunțarea la cealaltă.

Lucrarea Logjam din 2015 a demonstrat o retrogradare la Diffie-Hellman de 512 biți de calitate export și a estimat cât ar costa atacarea unor grupuri mai mari și foarte refolosite cu resurse semnificative. Demonstrația a fost concretă, estimările au fost estimări, iar niciuna nu a fost dovada că o anumită sesiune VPN a fost decriptată.

Citați lucrarea pentru mecanism și pentru retrogradarea demonstrată, nu ca măsurătoare a implementării dumneavoastră. Statisticile vechi despre câți servere partajau un grup implicit descriu internetul acelui an, nu o rețea pe care o puteți inspecta astăzi. Ce merită păstrat este întrebarea: dacă dispozitivele dumneavoastră mai negociază un grup mic sau slab validat.

Standardizat nu înseamnă slab

RFC 7919 definește grupuri de corp finit cu nume, astfel încât ambele capete să cadă de acord asupra unui grup după identificator și să aplice o politică consecventă. A fi standardizat este un avantaj, pentru că elimină ambiguitatea negocierii și permite unei implementări să refuze dimensiuni neacceptate. Un grup cu nume este slab doar când dimensiunea sa este sub politica pe care pretindeți că o urmați, nu pentru că apare într-un document. Aceeași logică se aplică grupurilor de curbe eliptice, care au o structură diferită și moduri de eșec diferite.

Țineți construcțiile separate când raționați despre ele. O concluzie despre Diffie-Hellman peste corp finit nu spune nimic despre X25519, iar o concluzie despre un grup MODP de 1024 de biți nu spune nimic despre unul de 3072 de biți. Politica de putere este pe mecanism, pe dimensiune și pe versiune de protocol, motiv pentru care sintagma criptografie puternică nu este o afirmație verificabilă.

Autentificarea este cealaltă jumătate și nu înlocuiește. Un grup puternic fără verificarea partenerului lasă un atacator la mijloc, iar un certificat valid nu poate salva un schimb de 768 de biți. Examinați-le ca două linii independente, apoi confirmați că ambele sunt într-adevăr negociate.

Citiți grupul negociat pe o conexiune reală

Citiți grupul negociat de pe dispozitiv, nu din șablonul de configurare. Șabloanele descriu intenția, iar valoarea interesantă este cea asupra căreia ambele capete au căzut de acord la ultima strângere de mână. Pe un punct final IPsec ieșirea de stare tipărește de obicei propunerea selectată, inclusiv grupul MODP.

Capturați acea linie înainte și după o schimbare de politică și păstrați ambele în registrul de modificări. Comparația este dovada.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

Dacă după schimbare starea arată încă grupul vechi, conexiunea nu a renegociat, iar modificarea configurației nu a dovedit nimic. Reporniți partenerul sau ștergeți asociația de securitate și apoi citiți din nou starea. O politică aplicată doar conexiunilor noi va lăsa tunelurile de lungă durată pe parametrii vechi atât timp cât rămân active.

Verificați grupul și identitatea partenerului separat

Separați ce protejează grupul de cine se află la celălalt capăt. Înregistrați metoda de schimb de chei, dimensiunea grupului și metoda de autentificare ca trei câmpuri, pentru că eșuează independent. Un tunel care a negociat un grup de 3072 de biți dar acceptă orice certificat nu este același risc ca unul care fixează un partener și folosește un grup de 2048 de biți.

Scrieți criteriile de acceptare înainte de începerea revizuirii, astfel încât rezultatul să fie o comparație, nu o opinie. O dimensiune minimă a grupului pentru fiecare versiune de protocol, o listă de permisiuni pentru grupurile cu nume și verificarea obligatorie a partenerului sunt suficiente pentru a face decizia mecanică. Ambiguitatea din acea listă este ce transformă o revizuire într-o dezbatere, iar dezbaterile nu se remediază. Atunci rezultatul este o listă de puncte finale care încalcă o regulă enunțată.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Închideți bucla recitind valorile negociate după remediere. Un fișier de configurare conform nu este dovada că un tunel l-a preluat. Ieșirea de stare și o strângere de mână nouă sunt dovada, iar colectarea lor ia mai puțin timp decât ședința despre dacă sunt necesare.