tls-auth versus tls-crypt: ce protejează fiecare în OpenVPN

Ambele opțiuni folosesc un fișier de cheie partajat și ambele fac traficul de handshake mai greu de falsificat, de aceea sunt tratate ca două nume pentru aceeași funcție. Nu sunt. Una semnează pachetele de control, cealaltă le și criptează, iar niciuna nu are legătură cu cifrul care vă protejează datele.

Această distincție contează când un profil nu se poate conecta, când o revizuire de securitate întreabă ce protejează cheia și când cineva presupune că fișierul suplimentar face tunelul criptat într-un mod nedefinit.

Ce protejează de fapt cheia partajată

Cheia folosită de aceste opțiuni aparține canalului de control: schimbului care negociază parametri, dovedește identități și derivă cheile de date. Este un secret partajat în prealabil pe care ambele capete trebuie să îl aibă înainte ca handshake-ul să poată continua. Fiindcă stă înaintea verificărilor de identitate, o cheie greșită oprește conversația mai devreme decât ar face-o o parolă greșită. Această ordine explică de ce modul de eșec este atât de silențios.

tls-auth folosește acel secret pentru a calcula un HMAC peste pachetele de control. Un pachet fără semnătură validă este aruncat înainte de a ajunge la procesarea TLS, mai costisitoare, motiv pentru care opțiunea este adesea descrisă ca un prim filtru, nu ca un substitut pentru TLS.

tls-crypt merge mai departe și criptează traficul de control protejat, pe lângă faptul că îl autentifică. Conținutul certificatelor, numele de cifrare negociate și alte detalii ale handshake-ului nu mai sunt vizibile în rețea, iar un observator fără cheie nu poate vedea nici măcar ce versiune TLS este încercată. Pentru o implementare care se teme să își dezvăluie amprenta VPN, acea proprietate este motivul principal de a o alege. Rămâne un secret de grup, nu o acreditare pentru fiecare utilizator.

Niciun mecanism nu emite identități. Cheia partajată este un secret de grup, iar oricine o deține poate îndeplini acel strat al verificării.

Unde diferă cele două opțiuni

Diferența observabilă este ce vede un observator. Cu tls-auth handshake-ul este vizibil, dar nu poate fi verificat fără cheie. Cu tls-crypt handshake-ul este opac pentru oricine nu deține cheia.

Configurația diferă și ea. tls-auth se folosește cu o valoare de direcție, așa că o parte folosește o jumătate din materialul cheii, iar cealaltă parte cealaltă jumătate. tls-crypt folosește o singură cheie în ambele direcții, deci directiva de direcție nu face parte din aranjamentul său.

În versiunile moderne cele două opțiuni se exclud reciproc. Un profil ar trebui să conțină una dintre ele, nu pe amândouă, iar serverul și clientul trebuie să cadă de acord care, cu material de cheie identic. Păstrarea unei directive vechi lângă una nouă este un reziduu comun de migrare. Eliminați-o pe cea inactivă pentru ca următorul cititor să știe care strat este cu adevărat în vigoare.

O variantă mai nouă, tls-crypt-v2, leagă fiecare client de propria cheie împachetată, astfel încât revocarea unui client nu necesită reemiterea cheii de grup. Merită cunoscută, dar este o altă opțiune și nu un sinonim pentru niciuna dintre cele două de aici.

De ce o nepotrivire pare că nu se întâmplă nimic

Când materialul partajat nu se potrivește, cealaltă parte aruncă pachetele fără să îi spună expeditorului de ce. Nu există nicio eroare de autentificare de citit, pentru că pachetul nu a ajuns niciodată la stratul care ar fi produs-o.

Clientul reîncearcă, serverul nu spune nimic, iar simptomul arată ca o problemă de rețea. Apoi oamenii repornesc serviciul, retastează parola contului sau elimină directiva de protecție ca să o «testeze», ceea ce schimbă implementarea în loc să o diagnosticheze.

Citiți în jurnalul serverului prima reclamație la nivel de pachet, nu ultima linie de reîncercare. Confirmați că ambele părți au aceeași opțiune cu material de cheie identic și că fișierul de cheie nu a fost regenerat doar pe o parte.

Eliminarea directivei nu este o reparație sigură. Dezactivează un strat de protecție pentru fiecare client, iar un tunel care funcționează după aceea dovedește doar că acel strat era nepotrivirea.

Ce mai trebuie configurat separat

Aceste opțiuni nu verifică cine este cealaltă parte. Validarea certificatelor, ancora de încredere și numele de server așteptat rămân cerințe separate, iar niciuna nu devine opțională pentru că există o cheie partajată.

De asemenea, nu aleg cifrul de date. Aceea este o negociere separată, controlată de setările canalului de date de pe ambele părți, iar un tunel protejat cu tls-crypt poate folosi în continuare un cifru pe care nu îl intenționați.

În fine, cheia partajată în sine are nevoie de grijă. Tratați-o ca pe un secret, distribuiți-o printr-un canal aprobat și înlocuiți-o când pleacă cineva care a deținut-o. Fiindcă este partajată, expunerea ei este expunerea fiecărui capăt care o folosește.