Un profil OpenVPN are trei blocuri de certificat: care este secret?

Deschizi un fișier .ovpn pentru a schimba o linie și găsești trei blocuri de base64 care arată toate ca date de autentificare. Unul este sigur de publicat, altul este la fel de sensibil ca o parolă, iar altul este o cheie publică ce nu înseamnă nimic dacă altceva nu a fost semnat cu perechea ei. Oamenii lipesc tot fișierul într-un fir de asistență pentru că blocurile par interschimbabile, și astfel o cheie de client ajunge într-o arhivă publică. A stabili ce face fiecare bloc explică cea mai mare parte a confuziei din jurul acestor profiluri și îți spune și ce defecțiuni trebuie să repari singur.

Un fișier, trei blocuri, sarcini diferite

Un profil obișnuit încorporează un bloc ca, un bloc cert și un bloc key între marcajele BEGIN și END, sau indică aceleași trei ca fișiere separate. Unele profiluri adaugă un al patrulea bloc pentru o cheie tls-auth sau tls-crypt, care este un secret partajat și nu un certificat. Clientul citește fiecare bloc conform directivei care îl numește, așa că etichetele contează mai mult decât ordinea în care apar.

Tratează profilul asamblat ca sensibil până când te-ai uitat cu adevărat în el. Un certificat public și o cheie privată pot sta la câteva linii unul de altul în același fișier, iar o captură de ecran care include antetul le poate conține pe amândouă. Acoperirea manuală a base64 vizibil nu este de încredere nici ea, pentru că un bloc parțial încă divulgă metadatele certificatului care numesc implementarea ta. Copierea celor trei directive fără valorile lor este de obicei suficientă pentru o întrebare utilă.

Directivele din jurul blocurilor decid cum sunt folosite. Schimbă ca și clientul are încredere într-o altă autoritate; schimbă cert fără a schimba key și strângerea de mână eșuează cu o nepotrivire care nu are nimic de-a face cu încrederea.

Blocul CA este public, cheia CA niciodată

O autoritate de certificare semnează certificate care leagă o cheie publică de o identitate, iar propriul ei certificat este ancora pe care un client o folosește ca să decidă dacă un lanț este de încredere. Acel certificat este public prin concepție: livrarea lui în fiecare profil este normală și de aceea o implementare auto-semnată poate funcționa fără o autoritate comercială.

Ceea ce nu trebuie să apară niciodată într-un profil de client este cheia privată de semnare a autorității. Clientul nu are nevoie de ea pentru nicio validare, iar prezența ei înseamnă că oricine are profilul poate crea identități noi pentru întreaga implementare.

Încrederea într-o autoritate este și mai îngustă decât sună. Un client care acceptă orice certificat semnat de CA va accepta în continuare un certificat emis pentru alt serviciu pe aceeași CA. Opțiunile care fixează rolul sau numele așteptat al serverului închid acel gol, iar Referința opțiunilor TLS enumeră directivele de verificare care fac asta.

Certificatele de server și de client indică direcții opuse

Certificatul serverului este ceea ce clientul inspectează ca să confirme că a ajuns la punctul final corect. Certificatul tău de client merge invers: serverul îl folosește ca să decidă că acest dispozitiv sau utilizator este unul pe care l-a înscris. Același format, direcție de încredere opusă.

O adresă nu este o identitate. A ajunge la IP-ul corect nu dovedește nimic despre cine a răspuns, de aceea verificarea numelui de gazdă sau a numelui certificatului aparține în continuare profilului. Nici parola contului nu înlocuiește în tăcere un certificat de client cerut, pentru că ambele sunt verificate în etape diferite și o implementare le poate cere pe amândouă.

Cheia privată a clientului este partea care trebuie să rămână privată. Dacă poate a fost expusă, ștergerea fișierului de pe laptopul tău nu schimbă nimic pe server, care va continua să accepte certificatul corespunzător până când operatorul îl revocă. A cere operatorului să înlocuiască sau să revoce acea identitate este singura soluție care călătorește cu tine.

Două solicitări care par identice și nu sunt

O cheie stocată în formă criptată cere o frază de acces înainte ca clientul să o poată folosi. Serviciul VPN poate cere separat o parolă de cont, iar cele două solicitări pot apărea la câteva secunde distanță cu aproape aceleași cuvinte. Fraza de acces protejează un fișier de pe discul tău; parola dovedește un cont unui server. Confundarea lor trimite oamenii către resetări de parolă care nu pot ajuta deloc.

Citește solicitarea înainte de a reseta ceva. O resetare a parolei de cont nu face nimic pentru o frază de acces uitată, un certificat revocat sau unul expirat, iar resetarea parolei când defecțiunea este validarea certificatului transformă o corectură de două minute într-un caz de asistență. Dacă reclamația menționează date de valabilitate, verifică mai întâi ceasul dispozitivului și apoi fereastra proprie a certificatului numit.

Când certificatul chiar a expirat, înlocuirea trebuie să vină de la cel care l-a emis. O cheie care aparține altcuiva nu este o cale de reînnoire, iar împrumutarea unui profil funcțional de la un coleg nu este nici ea.

Ce dovedește o strângere de mână curată și ce nu

A ajunge la o strângere de mână TLS finalizată înseamnă că relația de identitate configurată a rezistat: certificatul serverului s-a înlănțuit la CA-ul tău, iar certificatul tău a fost acceptat. Nu spune nimic despre politica de jurnalizare a operatorului și nimic despre dacă aplicațiile tale vor funcționa după ce tunelul este ridicat.

Rutele și DNS sunt etape ulterioare ale conexiunii, așa că un gazdă de intranet inaccesibilă după o autentificare reușită este o problemă de conectivitate și nu de certificat. Lucrează la acel strat în loc să schimbi datele de autentificare și ține împreună originea profilului, materialul lui privat și verificările lui de identitate când îl dai cuiva.