OpenVPN tls-crypt-v2: što rade klijentski ključ i zamotani blob
Profil tls-crypt-v2 sadrži klijentski kontrolni ključ i zamotanu kopiju koju samo poslužitelj može otvoriti. Držite svaki objekt i svaki korak umirovljenja odvojeno.
Lijepljenje profila tls-crypt-v2 u tiket izgleda bezopasno dok ne prebrojite što datoteka sadrži. Klijentski ključ kontrolnog kanala stoji pokraj šifrirane kopije istog tog ključa, a treći objekt, ključ za zamatanje, nikada ne napušta poslužitelj koji prihvaća. Ta tri odgovaraju na različita pitanja o skrbništvu, dijeljenju i umirovljenju. Njihovo razdvajanje rješava većinu rasprava o politici prije nego što počnu.
Što profil zapravo sadrži
Klijentska polovica tls-crypt-v2 jest ključ plus zamotana kopija istoga. Klijent rabi obični ključ za zaštitu kontrolnog kanala i predaje zamotanu kopiju poslužitelju tijekom postavljanja, pa poslužitelj vraća isti ključ bez pohrane čiste kopije po klijentu. Ključ za zamatanje omogućuje to vraćanje i pripada samo strani koja prihvaća. Sve niže slijedi iz toga gdje ta tri objekta žive.
| 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 |
Čitajte tablicu po skrbništvu, a ne po imenu, i posljedice se same pokazuju. Gubitak ključa za zamatanje skup je događaj jer ništa u profilu ne može rekonstruirati ključ, a pošteni oporavak jest ponovno izdavanje grupe. Procurio profil jeftiniji je ali mnogo češći, jer ljudi lijepe profile u tikete vjerujući da zamotana kopija čini datoteku sigurnom za dijeljenje. Dva kvara traže različite odgovore, i to je razlog zašto se objekti drže odvojeno.
Zašto zamotana kopija nije cijela priča
Profil nosi upotrebljiv klijentski materijal zajedno sa svojim zamotanim parnjakom, pa zaštita kopije za poslužitelj ne govori ništa o zaštiti datoteke. Blob je siguran za prijenos i nesiguran za objavljivanje. Metapodaci u njemu vidljivi su svakome tko primi blob, uključujući svakoga tko kasnije pročita tiket u koji je bio zalijepljen.
Tretirajte profil kao vjerodajnicu, a ne kao primjerak konfiguracije. Procurila datoteka daje svome držaču radni klijentski identitet dok poslužitelj ne prestane prihvaćati taj identitet, a zamatanje ne čini ništa u vezi s tim prozorom. Izdajte jedan profil po klijentu kako povlačenje ostane odluka o jednoj datoteci, i sigurnosno kopirajte ključ za zamatanje odvojeno od konfiguracije poslužitelja koju omogućuje. Nijedna od tih navika ne popravlja kompromitirani profil, ali obje određuju kako brzo će sljedeći biti obuzdan.
Gdje verifikacijska kuka stoji u rukovanju
Verifikacijska kuka izvodi se prije nego se TLS slog izloži, a njezin je posao pregledati metapodatke koje nosi zamotani blob. Prima te metapodatke plus malo, dokumentirano okruženje, i ima manje s čime raditi od autentifikacijske kuke. Pretpostavka da vidi korisnička imena, stanje sesije ili varijable dodataka uobičajen je način na koji se ta kuka loše piše. Pročitajte vlastiti odjeljak priručnika te kuke umjesto posuđivanja očekivanja od druge kuke.
Njezin izlazni status jest odluka: rezultat različit od nule odbija klijenta, a rezultat nula pušta rukovanje dalje. Politika zato mora reći što se događa kad metapodaci nedostaju, ne mogu se raščlaniti ili su neočekivani. Prvo napišite put odbijanja, a zatim odlučite koje su vrijednosti prihvatljive.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shTa dva retka čine površinu politike na poslužitelju: jedan imenuje ključ za zamatanje, drugi imenuje program koji prosuđuje svakog klijenta. Sve zanimljivo živi u skripti, koja zaslužuje verzijsko upravljanje i isti pregled kao i svako drugo pravilo pristupa.
Račun, potvrda i kontrolni ključ umirovljuju se odvojeno
Rano prihvaćanje kontrolnog kanala nije autentifikacija, jer se događa prije provjere TLS identiteta i prije ikakve autorizacije računa. Onemogućiti račun, opozvati potvrdu i odbiti klijentski kontrolni ključ tri su radnje s tri mehanizma. Implementacija koja izvede samo jednu od njih ima prazninu, a ne politiku. Uskladite troje namjerno i zabilježite koja faza izvršava koje ovlasti.
Vrijeme je druga razlika. Promijenjeni popis prihvaćanja primjenjuje se na nova rukovanja, dok uspostavljene sesije nastavljaju raditi dok ih nešto ne prekine. Brojanje unosa na novom popisu kao dokaz da su stare sesije završile jest način na koji uklonjeni klijent ostaje povezan satima.
Neusklađene ovlasti ostavljaju dvije rupe koje je lako naći u praksi. Račun može biti onemogućen dok njegov kontrolni ključ još otvara rukovanje, a potvrda može biti opozvana dok politika metapodataka još prima istog klijenta. Oboje je ista pogreška na različitim mjestima, jer je operater jedan popis smatrao cijelom ovlašću. Stavite tri popisa jedan uz drugi u trenutku uklanjanja i pogreška postaje vidljiva.
Izdavanje i povlačenje profila
Izdavanje je lakša polovica: stvorite klijentski ključ na strani koja prihvaća, predajte profil točno jednom vlasniku, držite materijal za zamatanje ograničenim i pokrenite isti verifikacijski program na svakom poslužitelju koji prihvaća. Jeftin ulazak svojstvo je cijele grupe, a ne najnovijeg računala. Drugi poslužitelj sa starijom ili labavijom skriptom tiho postaje najslabiji put u implementaciji.
Povlačenje traži tri koraka u namjernom redu. Odbijte klijenta u verifikacijskoj kuki da nova rukovanja propadnu, opozovite njegovu potvrdu ako se rabi PKI i onemogućite račun da kasnija autorizacija nema što autorizirati. Zatim prekinite sesije koje je staro prihvaćanje dopuštalo, jer neće primijetiti nijedno od troje. Vježbajte slijed na klijentu koji si možete priuštiti slomiti.
Metapodaci u profilu jesu ulaz za tu politiku, a ne dokaz da kontrola pristupa već postoji. Projektni dokument OpenVPN 2.6 opisuje objekte i granicu koju povlače, dok provedba ostaje na operateru.