Un handshake VPN eșuat este cu adevărat un atac de downgrade?

Un handshake care se termină cu o eroare pare un atac până te uiți la mesaj, și de cele mai multe ori este aritmetică: nicio propunere comună, un certificat expirat sau un pachet care nu a ajuns niciodată. Un atac de downgrade este ceva precis: un adversar care împinge ambele capete spre un comportament mai slab decât ar fi ales, și lasă dovezi diferite. Dacă tratezi fiecare eșec ca răutate, cauți o victimă care poate nu există, iar dacă tratezi un downgrade real ca eroare de configurare, rezultatul mai slab rămâne pe loc. Cele două erori costă diferit, și doar una este ieftin de corectat.

Ce schimbă de fapt un atac de downgrade

Scopul nu este să spargă cifrul și nici să ghicească o cheie. Scopul este să influențeze negocierea astfel încât ambele părți să se oprească la o versiune mai veche sau la un algoritm mai slab pe care atacatorul îl poate gestiona, sau să facă o parte să creadă că cealaltă acceptă doar asta.

Ce se schimbă este acordul, nu autentificarea. Dacă atacatorul poate modifica oferta fără a fi detectat, părțile pot finaliza în continuare un handshake și se pot autentifica reciproc, dar cu parametri pe care atacatorul îi preferă. De aceea întrebarea interesantă este dacă negocierea în sine este acoperită de protecția integrității.

De ce negocierea în sine trebuie autentificată

TLS 1.3 face această protecție explicită. Un client care a oferit versiunea mai nouă poate detecta un server care a revenit în silențiu, deoarece valoarea aleatorie a serverului poartă un model fix când negociază 1.2 sau mai jos, iar clientul trebuie să întrerupă când o vede. Întreaga transcriere este acoperită și de mesajele finale, așa că o modificare oriunde în negociere eșuează mai târziu în loc să treacă în silențiu.

Versiunile mai vechi ale protocolului aveau povești mai slabe, și exact de aceea regulile de revenire contează. Un punct final TLS 1.0 în aceeași configurație nu este un atac de downgrade; este un rezultat permis pe care ați ales să îl permiteți. Distincția este dacă rezultatul mai slab a venit dintr-o decizie protejată sau dintr-o cale neprotejată pe care un intermediar putea influența. Odată formulat astfel, majoritatea incidentelor se reduc la o întrebare de configurare.

IKEv2 se comportă diferit, dar se sprijină pe aceeași idee. Propunerea este purtată într-un schimb care autentifică ulterior ambele părți, așa că un echipament intermediar care rescrie algoritmii rupe autentificarea în loc să o dirijeze. Canalul de control al OpenVPN își protejează negocierea cu TLS și apoi folosește acel canal pentru a conveni cifrurile canalului de date, de aceea linia de jurnal a canalului de control este cea interesantă.

Compatibilitatea configurată nu este un atac

Un administrator poate permite deliberat opțiuni mai vechi pentru a sprijini un client documentat, iar decizia este vizibilă în configurație. Un atacator nu poate crea acea configurație; poate doar exploata o cale care îi permite să influențeze oferta.

Reparația periculoasă este cea care elimină dovada diferenței. Activarea fiecărei opțiuni vechi, dezactivarea verificării certificatelor sau acceptarea oricărui cifru pentru ca o eroare să dispară lărgește ceea ce punctul final va accepta și elimină verificările care ar fi raportat rezultatul mai slab.

Dacă trebuie să păstrați o opțiune veche, numiți motivul și clientul în comentariul configurației, apoi limitați opțiunea la profilul care are nevoie de ea. O excepție de compatibilitate limitată la un singur listener este auditabilă; una aplicată global este doar o valoare implicită mai slabă pe care nimeni nu își amintește că a ales-o.

Citiți eșecul înainte de a numi o cauză

Păstrați șirul exact al erorii, versiunile clientului și serverului și momentul înainte de orice modificare. Apoi clasificați: părțile nu au fost de acord asupra unei propuneri, calea pachetelor a eșuat sau o parte a respins un parametru pe care îl accepta cândva?

O nepotrivire de propunere numește de obicei versiunile sau algoritmii vinovați și eșuează în același punct de fiecare dată. O problemă de rutare sau MTU se blochează sau expiră, și adesea variază în funcție de rețea. Un certificat expirat produce o eroare de verificare, nu de negociere.

Nimic din toate acestea nu este dovada unui atacator. A atribui o cauză răuvoitoare la primul eșec este greșeala, pentru că ascunde bugul determinist care va eșua din nou mâine.

Confirmați ce s-a selectat de fapt

După orice corecție, citiți rezultatul negociat în loc să presupuneți că conexiunea a urcat. O conexiune care reușește pentru că verificarea a fost eliminată este rezultatul pe care încercați să îl evitați. Următoarele două comenzi arată versiunea și cifrul alese pentru un punct final cu TLS în față, plus linia canalului de control din jurnalul unui server OpenVPN.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Comparați rezultatul cu configurația pe care o intenționați, nu cu ce se conectează acum. Dacă versiunea selectată este mai veche decât minimul permis, profilul sau lista de revenire este locul de căutat, iar răspunsul este să corectați acea listă, nu să declarați un atac și să reconstruiți totul în jurul lui.