De ce AES-256 nu descrie o suită de criptare VPN

Întrebați ce criptare folosește un VPN și răspunsul vine de obicei într-un singur cuvânt: AES-256, sau ChaCha20, sau poate WireGuard. Acel răspuns numește o componentă a unui strat, în timp ce ceea ce protejează cu adevărat conexiunea este un set de algoritmi care îndeplinesc patru roluri diferite. Confundarea componentei cu aranjamentul este cea mai frecventă greșeală în aceste discuții și produce comparații care nu pot fi rezolvate.

Patru sarcini într-o singură conexiune

Criptarea în bloc transformă textul clar în text cifrat pentru canalul de date, iar cheia sa este derivată, nu transmisă. Protecția integrității detectează modificarea, ceea ce este o sarcină separată chiar și atunci când o singură construcție le face pe amândouă. Stabilirea cheilor produce materialul comun de trafic, iar autentificarea partenerului decide cine este la celălalt capăt. Dacă lipsește oricare dintre ele, conexiunea nu este sigură, oricât de puternică ar fi partea rămasă.

Unele proiecte unesc două roluri într-unul. AES-GCM și ChaCha20-Poly1305 sunt construcții de criptare autentificată, așa că confidențialitatea și integritatea vin împreună; AES-CBC nu este, și are nevoie de un cod de autentificare a mesajului separat, cu propria cheie. De aceea citirea unei propuneri ca un sac de numere independente citește greșit cele proiectate ca perechi.

Rolurile stau și pe straturi diferite, de aceea același cuvânt poate însemna lucruri diferite în două produse. Un cifru de bloc din ESP și un cifru de bloc din TLS sunt aceeași primitivă în negocieri diferite cu cerințe diferite. De aceea citarea unei primitive fără modul și stratul ei poate fi mai rea decât necitarea nimicului.

De ce numele unui cifru nu spune aproape nimic

Luați în serios pentru o clipă expresia AES-256: identifică un cifru de bloc și o dimensiune a cheii. Nu spune nimic despre modul de operare, despre dacă integritatea este asigurată, nici despre cum au fost stabilite cheile sau cum a fost autentificat partenerul. Două produse pot ambele să promoveze AES-256 și să difere în tot restul, inclusiv unul care îl asociază cu un mod neautentificat și altul care folosește un mod AEAD cu schimb de chei modern.

TLS 1.3 a adus această separare în standard, ceea ce este o corecție utilă pentru oricine a învățat vocabularul mai vechi. Suitele sale de cifrare numesc doar AEAD-ul și hash-ul, în timp ce grupurile de schimb de chei și algoritmii de semnătură sunt negociate ca parametri separați. De aceea numele unei suite TLS 1.3 nu este comparabil cu numele unei suite TLS 1.2 pe picior de egalitate, deși ambele apar în același câmp al unui fișier de configurare. Un auditor care compară cele două șiruri direct trage o concluzie pe care protocolul nu o susține. Citiți și grupul negociat și parametrii de semnătură, altfel comparația este incompletă.

WireGuard alege calea opusă și elimină negocierea aproape complet: protocolul impune un set fix de algoritmi, așa că două implementări fie interoperă, fie nu. Este o alegere de proiectare legitimă și înseamnă și că întrebarea ce suită negociază WireGuard nu are un răspuns care să merite o comparație. Dacă îl auditați, citiți specificația o dată și apoi auditați gestionarea cheilor din jurul ei în locul negocierii.

Stratul decide vocabularul

O implementare IPsec negociază de două ori: o propunere IKE pentru canalul de control și o transformare ESP pentru date, iar cele două pot diferi în mod legitim. Citirea primeia și presupunerea că o descrie pe a doua este o sursă frecventă de confuzie în timpul unui audit, pentru că fișierul de configurare le menționează pe amândouă, iar cea interesantă este a doua.

Un nume disponibil într-o bibliotecă nu este implementat automat pentru o altă cale de date. De aceea afirmația că produsul nostru acceptă AES-256 este mai slabă decât sună, și de aceea o problemă de interoperabilitate se rezolvă de obicei găsind intersecția întreținută, nu activând fiecare algoritm vechi pe ambele părți.

Specificația TLS 1.3 este cel mai clar exemplu publicat al separării, pentru că definește suita ca o pereche și mută restul în propria negociere. Odată ce acea formă este familiară, propunerea IPsec și singurul set fix WireGuard se citesc ca variante ale aceleiași idei.

Citiți rezultatul negociat, apoi opriți-vă

O propunere configurată nu este dovada a ceea ce au ales două părți. Sesiunea vie poartă răspunsul, și orice implementare obișnuită îl poate raporta fără a captura pachete.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

În ieșire citiți algoritmii selectați, nu lista oferită. Dacă răspunsul este mai slab decât a intenționat politica, corecția aparține configurației propunerii pe una dintre părți, iar o nepotrivire se manifestă în implementările moderne de obicei ca o negociere eșuată, nu ca o retrogradare silențioasă.

Apoi amintiți-vă ce nu acoperă suita. Rute, permisiuni ale aplicațiilor, jurnalizare și păstrare sunt decizii separate cu propria revizuire, iar un aranjament criptografic compatibil nu spune nimic despre ele. Discuția despre cifru merită purtată, dar răspunde la o întrebare mai îngustă decât cea pe care majoritatea oamenilor o pun de fapt.

Păstrați vocabularul precis și argumentul se scurtează. O suită este un set de roluri pe un strat, un cifru este o componentă, iar rezultatul negociat este singurul lucru care descrie conexiunea pe care o aveți cu adevărat. Restul din comparație este decor.