Certificat VPN auto-semnat: ce înseamnă și în ce are încredere

Aici fac cea mai multă pagubă două convingeri: că un certificat VPN auto-semnat înseamnă că tunelul nu este criptat, și că instalarea a tot ce a cerut clientul VPN afectează doar VPN-ul. Niciuna nu supraviețuiește contactului cu o implementare reală. Un certificat auto-semnat descrie o relație de semnătură, nu un verdict de securitate, iar amploarea încrederii pe care o adăugați depinde de depozitul în care ajunge. Am văzut un centru de asistență importând o rădăcină de furnizor într-o mașină Windows pentru a reduce la tăcere un avertisment, apoi petrecând o după-amiază explicând de ce browserul a încetat să se plângă de un portal fără legătură. Cele două jumătăți ale acestei întrebări merg împreună, așa că tratați-le ca una singură.

Un certificat nu este un depozit de încredere

Fișierul pe care îl prezintă serverul poartă o cheie publică, un nume de subiect, un nume de emitent, date de valabilitate și extensii. Auto-semnat înseamnă că subiectul și emitentul sunt aceeași entitate, iar semnătura se verifică cu cheia proprie a certificatului. Nimic din această definiție nu spune că conexiunea este slabă și nimic nu spune că clientul o va accepta.

Acceptarea vine de altundeva: un fișier CA către care îndreptați clientul, o amprentă pe care o comparați manual sau o rădăcină care se află deja într-un depozit pe care clientul îl citește. O implementare poate fi perfect sănătoasă în timp ce certificatul ei ar eșua la fiecare test public. openssl verify față de pachetul de sistem va raporta un emitent necunoscut, iar acel raport este corect, nu un defect.

Opțiunea ca a OpenVPN este cazul cel mai clar de încredere limitată la aplicație. Acel fișier numește ancorele pe care clientul le va accepta și poate conține o CA privată sau, într-o implementare mică, certificatul auto-semnat al serverului însuși. Versiunea 2.6 acceptă și --peer-fingerprint pentru a fixa o amprentă SHA-256 în loc să distribuie un fișier CA. WireGuard stă și mai departe: nu are deloc certificate, doar o cheie publică statică pentru fiecare peer, așa că întrebarea auto-semnării nu i se aplică.

Unde instalați încrederea decide cine o moștenește

Puneți același certificat în trei locuri și obțineți trei raze de explozie diferite. Un pachet citit doar de clientul VPN afectează acel client. O rădăcină în depozitul sistemului de operare afectează fiecare program care consultă acel depozit. Un browser cu propria bază de date de încredere poate ignora ambele, motiv pentru care un avertisment poate supraviețui unui import care părea să funcționeze.

Pe Debian sau Ubuntu, plasarea unui fișier în /usr/local/share/ca-certificates/ și rularea update-ca-certificates modifică pachetul la nivel de sistem. Pe Windows, certutil -addstore -f Root scrie în depozitul mașinii și necesită un prompt ridicat, în timp ce adăugarea -user vizează depozitul utilizatorului curent; cele două nu sunt interschimbabile. Firefox își ține propria bază de date NSS, așa că un import la nivel de sistem operativ poate să nu apară niciodată acolo.

Amploarea contează din cauza a ceea ce poate face o autoritate. O CA emitentă poate semna nume cu care nu are nicio relație, așa că tot ce are încredere în acel depozit va accepta acele semnături. O singură frunză fixată nu poate face asta; autentifică exact o identitate de peer. Dacă scopul este conectarea unui VPN, o CA limitată la aplicație sau o frunză fixată reușesc, în timp ce o rădăcină la nivel de mașină este o concesie mult mai mare decât cere simptomul.

Încă criptați fără o CA publică

Strângerea de mână TLS derivă chei de sesiune indiferent dacă certificatul peer-ului se înlănțuie cu ceva în care aveți deja încredere. Auto-semnat nu înseamnă text simplu și nu înseamnă că traficul este lizibil în zbor. Înseamnă că clientul nu are niciun motiv a priori să creadă că cheia aparține serverului pe care l-a cerut.

În acel gol trăiesc atacurile reale. Un client configurat să accepte orice certificat, fie prin setarea de verificare dezactivată, fie printr-un buton de încredere-oricum apăsat o dată și uitat, va cripta bucuros către oricine răspunde. Interceptarea are loc în pasul de autentificare, înainte ca datele aplicației să se miște. Criptarea fără verificarea identității ține un observator pasiv afară și face puțin altceva.

Încrederea în emitent nu sare peste verificarea numelui

Validarea lanțului, potrivirea numelui și scopul certificatului sunt decizii separate. Un lanț poate fi valid în timp ce numele este greșit, iar un nume poate potrivi în timp ce certificatul a fost emis pentru alt rol. RFC 5280 definește câmpurile care poartă aceste restricții, iar cât de strict le aplică un client este o chestiune de fiecare aplicație.

OpenVPN face separarea vizibilă. verify-x509-name fixează subiectul așteptat prin potrivirea name, name-prefix sau subject. remote-cert-tls server cere ca certificatul peer-ului să fie utilizabil ca certificat de server, ceea ce respinge un certificat doar de client chiar și atunci când emitentul este de încredere. Niciuna dintre cele două setări nu este înlocuită prin trimiterea unui fișier CA.

Inspectați certificatul înainte de a decide ceva:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName arată cine l-a emis, pentru ce nume și până când.
• openssl verify -CAfile ca.crt server.crt verifică dacă lanțul pe care intenționați să îl trimiteți validează într-adevăr frunza.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error funcționează pentru puncte finale TLS precum un portal web; protocolul OpenVPN pe 1194 nu este un flux TLS simplu, deci acel test nu se aplică acolo.

Un certificat cu data expirată, fără subjectAltName pentru numele la care vă conectați sau fără utilizarea serverAuth eșuează indiferent cât de atent a fost instalată ancora.

Cinci verificări înainte de a accepta unul

Comparați amprenta pe un canal care nu este conexiunea pe care încercați să o reparați: o consolă, un instalator pe care îl aveți deja, un fișier de configurare semnat. openssl x509 -in server.crt -noout -fingerprint -sha256 pe server și aceeași valoare în jurnalul clientului sunt suficiente pentru a ști că priviți un singur obiect.

Apoi decideți ce instalați: o frunză sau o autoritate care poate bate mai multe. Apoi decideți unde merge și numiți aplicațiile care citesc acel depozit. Notați calea de îndepărtare cât încă v-o amintiți, pentru că încrede-te-și-continuă este felul în care un import temporar devine permanent.

În final, planificați schimbarea. Un certificat sau o amprentă fixate trebuie actualizate prin același canal de încredere atunci când certificatul se rotește, iar o CA privată are propriul ciclu de viață de emitere și revocare. Dacă cheia privată se scurge, reîncrederea într-o copie a aceluiași certificat nu repară nimic; identitatea trebuie înlocuită.

Dacă un avertisment supraviețuiește tuturor celor cinci verificări, întrebarea utilă nu este ce buton îl reduce la tăcere, ci ce depozit citește de fapt clientul și de unde a venit acea rădăcină. Răspundeți la asta, iar importul pe care sunteți pe cale să îl faceți devine o decizie în loc de un reflex.