Criptare simetrică vs. cu cheie publică într-o VPN: ce face fiecare
O VPN autentifică partenerii cu chei publice, apoi criptează pachetele cu chei de sesiune derivate. Tratați certificatele și cheile de trafic ca obiecte distincte.
Oamenii descriu o VPN ca „cea care folosește criptare cu cheie publică“ și apoi își imaginează fiecare pachet încuiat cu certificatul serverului. Această imagine este greșită într-un mod care contează când citești un fișier de configurare sau o captură de pachete. Jumătatea cu cheie publică a unui VPN ține de a dovedi cine este partenerul și de a conveni asupra materialului secret; jumătatea simetrică este cea care protejează efectiv traficul, pachet cu pachet, pe toată durata sesiunii.
Cele două jumătăți au durate de viață, moduri de eșec și lucruri care pot fi publicate în siguranță diferite. Odată ce le separi, întrebări ca „RSA 2048 este mai slabă decât AES-128“ nu mai încurcă, pentru că nu au fost niciodată comparabile.
Trei operații care se confundă
Criptografia cu cheie publică este o umbrelă peste cel puțin trei operații distincte. O semnătură dovedește că deținătorul unei chei private a aprobat un anumit mesaj. Acordul de chei permite două părți să derive un secret comun din valori schimbate public. Criptarea cu cheie publică ascunde datele sub cheia publică a cuiva, astfel încât doar cheia privată le poate deschide.
Handshake-urile VPN folosesc mai ales primele două. Un certificat nu este o cheie de criptare; este o declarație semnată care leagă un nume de o cheie publică și permite celeilalte părți să decidă dacă are încredere în cheia tocmai primită. Stabilirea cheilor în TLS 1.3, de exemplu, se bazează pe acordul de chei (EC)DHE plus semnături de certificat, nu pe criptarea sesiunii cu cheia publică a serverului.
Ce produce de fapt handshake-ul
Într-un handshake modern, fiecare parte generează o pereche de chei efemeră, schimbă jumătățile publice și calculează un secret comun care nu trece niciodată prin fir. Acel secret trece apoi printr-o funcție de derivare a cheilor pentru a produce chei separate pentru fiecare direcție, plus nonce-urile și materialul IV de care are nevoie stratul de înregistrări. WireGuard face asta cu construcția sa bazată pe Noise; TLS 1.3 o face cu HKDF pe transcrierea handshake-ului.
Acreditarea pe termen lung — certificat și cheie privată, sau o cheie WireGuard statică — autentifică schimbul. Ea semnează sau se amestecă în transcriere, astfel încât un străin să nu poată finaliza handshake-ul în locul partenerului. După aceea, acreditarea nu face muncă pe pachet. Dacă ar face, fiecare pachet ar cere o operație cu cheie privată, iar un tunel ocupat ar fi limitat de cea mai lentă operație din stivă.
Urmează două efecte secundare. Întâi, cheile de sesiune sunt proaspete de fiecare dată, așa că un atacator care fură mai târziu cheia pe termen lung nu poate decripta sesiuni înregistrate anterior, dacă acordul a fost efemer. Al doilea, o cheie de sesiune scursă compromite o sesiune, nu identitatea.
De ce volumele mari de date folosesc chei simetrice
Cifrurile simetrice gestionează bine volumul: AES-GCM sau ChaCha20-Poly1305 procesează fiecare pachet cu o cheie deja în memorie, autentifică antetul și incrementează un contor. Partea receptoare verifică nonce-ul și eticheta de autentificare și aruncă tot ce eșuează sau se repetă. Este suficient de ieftin pentru a rula la viteza liniei pe hardware obișnuit, iar aceeași construcție oferă confidențialitate și integritate într-o singură trecere.
Construcția este și locul unde trăiesc majoritatea erorilor de implementare. Un nonce repetat în GCM sparge confidențialitatea și autenticitatea deodată, de aceea protocoalele derivă chei pe direcție și țin un contor sau o epocă explicite. Dacă citești o captură de pachete și lungimea textului cifrat corespunde textului clar plus un adaos fix, lucrează stratul simetric, nu o operație cu cheie publică pe pachet.
Durata de viață, reînnoirea cheilor și secretul înainte
Cheile de sesiune sunt menite să expire. TLS 1.3 permite unui mesaj KeyUpdate să rotească cheile de trafic; WireGuard reînnoiește o sesiune după un timp sau un număr de mesaje configurat și păstrează cheia veche scurt pentru pachetele în curs. OpenVPN renegociază cheile canalului său de date după un program, iar reneg-sec controlează intervalul.
Niciuna dintre aceste rotații nu este același lucru cu reînnoirea unui certificat. Un certificat poate fi valabil un an în timp ce cheile de sesiune se schimbă la fiecare câteva minute, iar un certificat poate fi înlocuit fără a atinge cheile tunelului care rulează. Când planifici o expirare, întreabă ce obiect rotești; răspunsul decide dacă clienții se reconectează sau doar reînnoiesc chei.
Citirea configurațiilor și a diagnosticului fără a amesteca obiectele
În practică alegi un protocol complet și primitivele pe care le suportă, nu asamblezi unul propriu. Cheia --tls-crypt a OpenVPN protejează canalul de control; canalul de date folosește cifruri simetrice negociate. Intrările PrivateKey și PublicKey ale WireGuard sunt material de identitate, iar cheile sale de transport sunt derivate intern. Citirea acelor câmpuri ca același tip de secret duce la erori precum lipirea unei chei publice unde ar trebui să fie una privată.
Ține materialul public separat de cel privat. Un certificat, o cheie publică WireGuard și o amprentă sunt sigure de partajat într-un tichet. O cheie privată, o cheie prepartajată și o cheie de sesiune exportată nu sunt. Când compari puteri, compară în interiorul unui tip: un identificator de curbă eliptică, o dimensiune a modulului RSA și o dimensiune a cheii AES măsoară lucruri diferite sub ipoteze diferite. Specificația TLS 1.3 este o referință utilă despre cum se potrivesc cele două straturi, chiar și când tunelul tău nu este TLS.