OpenVPN tls-crypt-v2: co dělají klientský klíč a zabalený blob
Profil tls-crypt-v2 obsahuje klientský řídicí klíč a zabalenou kopii, kterou otevře jen server. Udržujte každý objekt i každý krok odvolání odděleně.
Vložit profil tls-crypt-v2 do tiketu vypadá neškodně, dokud nespočítáte, co soubor obsahuje. Klientský klíč řídicího kanálu stojí vedle šifrované kopie téhož klíče a třetí objekt, klíč pro zabalení, nikdy neopustí přijímající server. Ty tři odpovídají na různé otázky o úschově, sdílení a odvolání. Jejich oddělení vyřeší většinu sporů o politiku dřív, než začnou.
Co profil skutečně obsahuje
Klientská polovina tls-crypt-v2 je klíč plus jeho zabalená kopie. Klient používá prostý klíč k ochraně řídicího kanálu a zabalenou kopii předá serveru při nastavení, takže server obnoví tentýž klíč, aniž by ukládal čitelnou kopii pro každého klienta. Klíč pro zabalení toto obnovení umožňuje a patří pouze přijímající straně. Vše níže plyne z toho, kde tyto tři objekty žijí.
| 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 |
Čtěte tabulku podle úschovy, ne podle názvu, a důsledky vyplynou samy. Ztráta klíče pro zabalení je drahá událost, protože nic v profilu ho nedokáže rekonstruovat a poctivé obnovení znamená znovu vydat skupinu. Uniklý profil je levnější, ale mnohem častější, protože profily vkládají do tiketů lidé, kteří věří, že zabalená kopie dělá soubor bezpečným ke sdílení. Obě selhání vyžadují jinou reakci, a proto se objekty drží odděleně.
Proč zabalená kopie není celý příběh
Profil nese použitelný klientský materiál spolu s jeho zabaleným protějškem, takže ochrana kopie pro server neříká nic o ochraně souboru. Blob je bezpečný k přenosu a nebezpečný ke zveřejnění. Metadata uvnitř jsou viditelná každému, kdo blob obdrží, včetně toho, kdo později přečte tiket, do kterého byl vložen.
Berte profil jako pověření, ne jako ukázkovou konfiguraci. Uniklý soubor dává držiteli funkční klientskou identitu, dokud server tuto identitu přestane přijímat, a zabalení s tím oknem nic nedělá. Vydávejte jeden profil na klienta, aby odvolání zůstalo rozhodnutím o jednom souboru, a zálohujte klíč pro zabalení odděleně od konfigurace serveru, kterou umožňuje. Ani jeden z těch návyků neopraví kompromitovaný profil, ale oba určují, jak rychle bude další zadržen.
Kde v handshake sedí ověřovací hook
Ověřovací hook běží dřív, než se vystaví TLS stack, a jeho úkolem je prohlédnout metadata nesená v zabaleném blobu. Dostává tato metadata plus malé, zdokumentované prostředí a má méně prostředků než autentizační hook. Předpoklad, že vidí uživatelská jména, stav relace nebo proměnné zásuvných modulů, je obvyklý způsob, jak se tento hook napíše špatně. Čtěte vlastní oddíl příručky k hooku, místo abyste si půjčovali očekávání z jiného hooku.
Jeho návratový stav je rozhodnutí: nenulový výsledek klienta odmítne a nulový výsledek nechá handshake pokračovat. Politika proto musí říct, co se stane, když metadata chybí, nejdou analyzovat nebo jsou neočekávaná. Napište nejdřív cestu odmítnutí, potom rozhodněte, které hodnoty jsou přijatelné.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shTy dva řádky jsou povrch politiky na serveru: jeden pojmenovává klíč pro zabalení, druhý program, který soudí každého klienta. Vše zajímavé žije ve skriptu, který si zaslouží správu verzí a stejnou revizi jako každé jiné pravidlo přístupu.
Účet, certifikát a řídicí klíč se odvolávají odděleně
Časné přijetí řídicího kanálu není autentizace, protože se odehrává před kontrolou identity TLS a před jakoukoli autorizací účtu. Deaktivace účtu, odvolání certifikátu a odmítnutí klientského řídicího klíče jsou tři akce se třemi mechanismy. Nasazení, které provede jen jednu z nich, má mezeru, ne politiku. Sladujte ty tři vědomě a zaznamenejte, který krok uplatňuje kterou pravomoc.
Časování je druhý rozdíl. Změněný seznam přijetí platí pro nové handshaky, zatímco už navázané relace běží dál, dokud je něco neukončí. Počítat položky v novém seznamu jako důkaz, že staré relace skončily, je způsob, jak odstraněný klient zůstane připojený hodiny.
Nesladěné pravomoci nechávají dvě díry, které se v praxi snadno najdou. Účet lze deaktivovat, zatímco jeho řídicí klíč stále otevírá handshake, a certifikát lze odvolat, zatímco politika metadat téhož klienta stále připouští. Obojí je stejná chyba na různých místech, protože operátor považoval jeden seznam za celou pravomoc. Položte tři seznamy při odstraňování vedle sebe a chyba se stane viditelnou.
Vydávání a odvolávání profilu
Vydávání je snazší polovina: vytvořte klientský klíč na přijímající straně, předejte profil právě jednomu vlastníkovi, držte materiál pro zabalení omezený a spouštějte stejný ověřovací program na každém přijímajícím serveru. Levné přijetí je vlastnost celé skupiny, ne nejnovějšího hostitele. Druhý server se starším nebo volnějším skriptem se tiše stane nejslabší cestou v nasazení.
Odvolání potřebuje tři kroky v promyšleném pořadí. Odmítněte klienta v ověřovacím hooku, aby nové handshaky selhaly, odvolejte jeho certifikát, pokud se používá PKI, a deaktivujte účet, aby pozdější autorizace neměla co autorizovat. Pak ukončete relace, které staré přijetí umožnilo, protože ty si ničeho z toho nevšimnou. Procvičte posloupnost na klientovi, kterého si můžete dovolit rozbít.
Metadata v profilu jsou vstupem pro tuto politiku, ne důkazem, že řízení přístupu už existuje. Návrhový dokument OpenVPN 2.6 popisuje objekty a hranici, kterou kreslí, zatímco vynucování zůstává na operátorovi.