OpenVPN fără CA: cum verifică peer-fingerprint partenerii

O implementare mică apelează la amprente pentru că o autoritate de certificare arată ca o infrastructură pentru care nimeni nu are timp. Instinctul este rezonabil, dar scurtătura pe care oamenii o aleg în schimb—copierea unui secret al canalului de date la ambele capete—nu este. O configurație peer-fingerprint păstrează structura TLS intactă: fiecare parte are în continuare propria cheie privată și propriul certificat, iar fiecare parte verifică în continuare cealaltă. Ceea ce se schimbă este unde este ancorată verificarea: de la un emitent de încredere la o listă scurtă de rezumate fixate. Deoarece un rezumat acoperă întregul certificat și nu un nume, reînnoirea devine operațiunea care chiar consumă timp.

La ce se angajează de fapt amprenta

Amprenta unui certificat este un rezumat al întregului certificat codificat DER, nu al cheii sale publice și nu al numelui subiectului său. De aceea două certificate cu nume identice și aceeași cheie, dar date de valabilitate diferite, au amprente diferite. Asta face fixarea precisă și tot asta face reînnoirea perturbatoare. O fixare nu poate însemna încredere într-o cheie în general, pentru că numește un singur artefact într-un moment al vieții sale. Oricine poate cunoaște rezumatul, iar cunoașterea lui nu demonstrează nimic prin sine.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

Deținerea cheii private corespunzătoare este ceea ce demonstrează că partenerul are acel certificat, iar rezumatul este modul în care cealaltă parte decide dacă se aștepta sau nu la acel certificat. Această separare este motivul pentru care acest design nu este vechea înțelegere cu secret comun: o cheie comună autentifică oricine cunoaște aceiași octeți, în timp ce o fixare autentifică un singur certificat. Un alt dispozitiv primește propria intrare în loc de o copie a aceluiași secret, ceea ce este o diferență mică în fișiere și mare în amploarea pagubei.

Harta este reciprocă, nu simetrică

Fiecare punct final are nevoie de două lucruri: propria cheie privată cu certificatul, și o declarație despre ce certificate de partener va accepta. La client acea declarație este rezumatul certificatului serverului; la server este lista rezumatelor clienților înregistrați. Un exemplu oficial pentru configurații mici pentru Community 2.6 arată aranjamentul cu peer-fingerprint, și merită citit înainte de a alege acest model de încredere pentru o implementare reală. Cele două direcții nu sunt o listă inversată și nu eșuează în același moment.

Adăugarea unui dispozitiv editează o listă de permisiuni pe server, fără a copia materialul privat al unui client existent și fără a muta cheia serverului nicăieri. Cele două direcții eșuează și independent, ceea ce este util la diagnosticare: partea care închide strângerea de mână este partea a cărei așteptare nu a fost îndeplinită. Dacă clientul respinge serverul, rezumatul nu corespunde certificatului prezentat. Dacă serverul respinge clientul, rezumatul acelui client lipsește din listă, sau clientul prezintă alt certificat decât cel înregistrat.

Înregistrare: cum se alătură un dispozitiv nou

Generați cheia și certificatul noului dispozitiv acolo unde va locui cheia privată, apoi mutați doar artefactul public la partea care trebuie să îl fixeze. Transferați rezumatul așteptat printr-un canal în care deja aveți încredere, și comparați certificatul complet în loc de un nume care pare familiar. Un rezumat copiat din aceeași descărcare neverificată ca certificatul demonstrează doar că cele două fișiere se potrivesc între ele. Este o verificare de consistență, nu de identitate, și este cel mai tăcut mod în care acest design slăbește.

Pe server, adăugarea rezumatului este o schimbare de configurație care trece prin managerul obișnuit și este urmată de o reconectare. Confirmați că dispozitivul nou se conectează și că un dispozitiv al cărui rezumat a fost eliminat nu mai face asta. Un test care acoperă doar cazul pozitiv lasă lista de permisiuni neverificată, iar exact în această stare veți fi peste șase luni.

Reînnoirea este momentul costisitor

Fiecare certificat expiră, iar un certificat nou are un rezumat nou chiar și când cheia și numele rămân aceleași. Sub un emitent, reînnoirea este transparentă pentru partenerii care au încredere în acel emitent; sub fixare, este un eveniment de înregistrare pentru fiecare partener care fixează certificatul.

Planificați ordinea înainte de data expirării, nu după. Distribuiți rezumatul nou părților care îl verifică, aplicați schimbarea și abia apoi înlocuiți certificatul la punctul final. Această ordine nu lasă nicio fereastră în care cele două părți nu sunt de acord asupra certificatului actual. Țineți sub revizuire și lista în sine, pentru că o listă fixată acumulează intrări pentru dispozitive retrase acum luni. Fiecare intrare învechită este o identitate care încă se autentifică dacă cheia ei supraviețuiește, așa că eliminarea uneia este o acțiune de securitate, nu o treabă de întreținere.

Ce nu decide harta de încredere

Autentificarea este un singur strat, iar harta fixată nu spune nimic despre pool-ul de adrese, rutele împinse, MTU-ul căii sau politica de firewall. Acestea rămân configurație separată cu moduri de eșec separate. Un tunel care se autentifică și nu trece niciun trafic este o investigație diferită de unul care nu se ridică niciodată.

Harta nu scalează nici la nesfârșit, iar o PKI bazată pe emitent este locul unde ajung implementările mai mari. Această preferință ține de operațiuni și nu de criptografie, pentru că adăugarea și retragerea identităților printr-o singură autoritate este mai ieftină decât editarea unei liste la fiecare partener pe măsură ce flota crește. Acolo unde o implementare de client nu acceptă opțiunea, răspunsul este un model de încredere compatibil pe care acel client îl documentează, sau un înlocuitor acceptat. Suprimarea avertismentului de verificare nu adaugă acel suport, iar toată valoarea designului este că verificarea tot are loc.