OpenVPN tls-crypt-v2: ce fac cheia clientului și blobul împachetat
Un profil tls-crypt-v2 conține o cheie de control a clientului și o copie împachetată pe care doar serverul o poate deschide. Țineți fiecare obiect și fiecare pas de retragere separat.
Lipirea unui profil tls-crypt-v2 într-un tichet pare inofensivă până când numărați ce conține fișierul. Cheia canalului de control al clientului stă lângă o copie criptată a aceleiași chei, iar un al treilea obiect, cheia de împachetare, nu părăsește niciodată serverul care acceptă. Acestea trei răspund la întrebări diferite despre custodie, partajare și retragere. Separarea lor rezolvă majoritatea disputelor de politică înainte să înceapă.
Ce conține de fapt profilul
Jumătatea client a tls-crypt-v2 este o cheie plus o copie împachetată a ei. Clientul folosește cheia simplă pentru protecția canalului de control și predă copia împachetată serverului în timpul configurării, astfel încât serverul recuperează aceeași cheie fără a stoca o copie în text clar pentru fiecare client. Cheia de împachetare face posibilă această recuperare și aparține doar părții care acceptă. Tot ce urmează derivă din locul unde trăiesc aceste trei obiecte.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
Citiți tabelul după custodie, nu după nume, iar consecințele apar de la sine. Pierderea cheii de împachetare este evenimentul costisitor, pentru că nimic dintr-un profil nu o poate reconstrui, iar recuperarea onestă este reemiterea grupului. Un profil scurs este mai ieftin, dar mult mai frecvent, pentru că oamenii lipesc profiluri în tichete crezând că copia împachetată face fișierul sigur de partajat. Cele două eșecuri cer răspunsuri diferite și de aceea obiectele sunt ținute separat.
De ce copia împachetată nu este toată povestea
Un profil poartă materialul utilizabil al clientului împreună cu omologul său împachetat, așa că protejarea copiei pentru server nu spune nimic despre protejarea fișierului. Blobul este sigur de transmis și nesigur de publicat. Metadatele din el sunt vizibile oricui primește blobul, inclusiv oricui citește mai târziu tichetul în care a fost lipit.
Tratați un profil ca pe o acreditare, nu ca pe un exemplu de configurare. Un fișier scurs îi dă deținătorului o identitate de client funcțională până când serverul încetează să accepte acea identitate, iar împachetarea nu face nimic în privința acelei ferestre. Emiteți un profil per client, astfel încât retragerea să rămână o decizie despre un singur fișier, și faceți copie de siguranță a cheii de împachetare separat de configurația serverului pe care o permite. Niciunul dintre cele două obiceiuri nu repară un profil compromis, dar ambele decid cât de repede va fi limitat următorul.
Unde stă cârligul de verificare în handshake
Cârligul de verificare rulează înainte ca stiva TLS să fie expusă, iar sarcina lui este să inspecteze metadatele purtate în blobul împachetat. Primește acele metadate plus un mediu mic și documentat, și are mai puțin cu ce lucra decât un cârlig de autentificare. A presupune că vede nume de utilizator, starea sesiunii sau variabile ale pluginurilor este modul obișnuit în care acest cârlig este scris prost. Citiți secțiunea de manual a cârligului însuși în loc să împrumutați așteptări de la alt cârlig.
Starea lui de ieșire este decizia: un rezultat diferit de zero refuză clientul, iar un rezultat zero lasă handshake-ul să continue. Politica trebuie deci să spună ce se întâmplă când metadatele lipsesc, nu pot fi analizate sau sunt neașteptate. Scrieți mai întâi calea de refuz, apoi decideți ce valori sunt acceptabile.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shCele două linii sunt suprafața politicii pe server: una numește cheia de împachetare, cealaltă numește programul care judecă fiecare client. Tot ce este interesant trăiește în script, care merită controlul versiunilor și aceeași revizuire ca orice altă regulă de acces.
Contul, certificatul și cheia de control se retrag separat
Acceptarea timpurie a canalului de control nu este autentificare, pentru că are loc înainte de verificarea identității TLS și înainte de orice autorizare a contului. Dezactivarea unui cont, revocarea unui certificat și refuzarea unei chei de control a clientului sunt trei acțiuni cu trei mecanisme. O implementare care face doar una dintre ele are o lacună, nu o politică. Împăcați cele trei în mod deliberat și înregistrați care pas exercită ce autoritate.
Timpul este a doua distincție. O listă de acceptare modificată se aplică handshake-urilor noi, în timp ce sesiunile deja stabilite continuă până când ceva le termină. Numărarea intrărilor din lista nouă ca dovadă că sesiunile vechi s-au încheiat este felul în care un client eliminat rămâne conectat ore întregi.
Autoritățile neîmpăcate lasă două găuri ușor de găsit în practică. Un cont poate fi dezactivat în timp ce cheia lui de control încă deschide un handshake, iar un certificat poate fi revocat în timp ce politica de metadate încă admite același client. Ambele sunt aceeași greșeală în locuri diferite, pentru că un operator a tratat o singură listă ca toată autoritatea. Puneți cele trei liste una lângă alta la momentul eliminării și greșeala devine vizibilă.
Emiterea și retragerea unui profil
Emiterea este jumătatea ușoară: creați cheia clientului pe partea care acceptă, predați profilul exact unui singur proprietar, țineți materialul de împachetare restricționat și rulați același program de verificare pe fiecare server care acceptă. Admiterea ieftină este o proprietate a întregului grup, nu a gazdei celei mai noi. Un al doilea server cu un script mai vechi sau mai lax devine în tăcere cea mai slabă cale din implementare.
Retragerea cere cei trei pași într-o ordine deliberată. Refuzați clientul în cârligul de verificare ca handshake-urile noi să eșueze, revocați certificatul dacă se folosește o PKI și dezactivați contul ca autorizarea ulterioară să nu aibă ce autoriza. Apoi terminați sesiunile pe care vechea acceptare le permitea, fiindcă nu vor observa niciuna dintre cele trei. Exersați secvența pe un client pe care vă puteți permite să-l rupeți.
Metadatele dintr-un profil sunt o intrare pentru acea politică, nu dovada că controlul accesului există deja. Documentul de proiectare OpenVPN 2.6 descrie obiectele și granița pe care o trag, în timp ce aplicarea rămâne la operator.