Co vlastně chrání přístupová fráze na soukromém klíči VPN

Výzvu, která se objeví při spuštění klienta VPN, lze snadno přečíst špatně. Není to heslo k účtu VPN, není to heslo k tunelu a jejím zadáním se neprokazuje, že je spojení bezpečné. Odemyká jednu uloženou reprezentaci soukromého klíče, aby klient mohl přečíst materiál klíče a použít ho k autentizaci. Vše, co se stane potom, je jiná otázka.

V praxi se odpověď láme na okrajích: lidé předpokládají, že fráze chrání běžící tunel, nebo že její změna odvolá kopii klíče, která už unikla. Oba předpoklady selhávají, a to tak, že zanechají přihlašovací údaj vystavený, zatímco operátor věří, že je vyřešeno.

Jeden dialog, několik různých tajemství

Přístupová fráze k soukromému klíči dešifruje soubor. Heslo k účtu vás autentizuje u služby. Heslo pro import PKCS#12 dešifruje balík obsahující klíč a jeho certifikát a nemusí být stejný řetězec jako vlastní fráze klíče. Tyto výzvy mohou vypadat téměř stejně, a hádání, které tajemství kam patří, je způsob, jak klíče skončí vložené do špatného pole.

Vlastní šifrování tunelu je čtvrtá věc. Datový kanál používá relační klíče dohodnuté během handshake; přístupová fráze soukromého klíče nemá žádnou roli při ochraně jednotlivých paketů. Pokud někdo může přečíst soubor klíče, může se pokusit frázi uhodnout offline, ale pokud může číst pakety, je fráze irelevantní.

Co šifrování na disku pokrývá

Šifrovaný klíč PEM má dvě podoby a hlavička vám řekne, kterou máte. Moderní forma PKCS#8 začíná -----BEGIN ENCRYPTED PRIVATE KEY-----; starší forma PEM, stále běžná ve starších instalacích OpenVPN, začíná -----BEGIN RSA PRIVATE KEY----- a nese Proc-Type: 4,ENCRYPTED a řádek DEK-Info hned pod ním. Soubor obsahuje soukromý klíč zašifrovaný klíčem odvozeným z vaší fráze, obvykle pomocí KDF založeného na hesle s uvedeným počtem iterací nebo pracovním faktorem. Dokumentace OpenSSL pkey pokrývá formáty a možnosti fráze, které se při čtení uplatňují.

Z toho plynou dva důsledky. Slabá fráze je napadnutelná offline tempem, které KDF dovolí, takže oprávnění souboru a přístup k zálohám jsou důležité i tehdy, když je soubor šifrovaný. A útočník, který získá jen soubor bez fráze, musí hádat; ten, kdo získá soubor i frázi, má klíč, přesně jako by nikdy nebyl šifrovaný.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 zobrazí hlavičku a u staršího souboru řádky Proc-Type a DEK-Info, které dokazují šifrování; jeden řádek sám o sobě není důkazem ani jedním směrem. Řádek pkey se ptá na frázi a vypíše jen veřejnou polovinu, což dokazuje, že soubor a fráze fungují bez odhalení soukromého klíče. Pro tuto kontrolu nepoužívejte -text: vypisuje soukromé komponenty, privateExponent, prime1, prime2 a zbytek, a tento výstup se nikdy nesmí nikam vložit, ani do tiketu, ani do chatu, ani do logu. Příkaz PKCS#12 také řekne, zda má balík samostatné heslo MAC nebo šifrování, což je dobré vědět, než ho předáte kolegovi.

Co přestane chránit po načtení klíče

Odemčení je pro tento proces jednosměrná událost. Klient požádá KDF o klíč, dešifruje soubor a drží soukromý klíč v paměti tak dlouho, jak potřebuje. Od té chvíle fráze nechrání nic z běžící relace: ani paměť procesu, ani výpis jádra, ani ladicí relaci připojenou ke klientovi, ani zálohu stroje pořízenou, když byl klíč používán.

Je to stejná hranice jako u klíče SSH s frází nebo odemčeného trezoru správce hesel. Zvyšuje cenu krádeže souboru v klidu a nic nedělá proti malwaru běžícímu pod vaším uživatelem, autorizované aplikaci, která žádá klienta o podpis, ani proti správci, který může číst paměť. Berte to jako jednu vrstvu, ne jako kontrolu, která činí klíč bezpečným ponechat bez dozoru.

Proč se výzva stále vrací

Klient, který se znovu ptá při každém opětovném připojení, nemusí být nutně rozbitý. Někteří klienti frázi ukládají do mezipaměti pro relaci, někteří ji ukládají do klíčenky OS a některé lze nasměrovat na pomocníka, který ji dodá, takže chování závisí na klientovi a jeho konfiguraci, ne na souboru klíče.

Pokud je opakovaná výzva skutečnou stížností, prozkoumejte možnosti ukládání do mezipaměti a autentizace klienta, než z klíče odstraníte šifrování. Odstranění fráze převede chráněný soubor na klíč v otevřeném textu a opětovné připojení ztichne na úkor jediné kontroly v klidu, kterou jste měli. Lepší odpověď je obvykle podporované úložiště přihlašovacích údajů se stejnými oprávněními souboru, která byste stejně použili.

Ztráta a expozice nejsou stejná oprava

Ztracenou frázi nelze z certifikátu obnovit. Certifikát je veřejný materiál, který váže jméno ke klíči; neobsahuje cestu zpět k soukromému klíči ani žádnou nápovědu k frázi. Praktické možnosti jsou autorizovaná záloha klíče nebo nová identita vydaná běžným procesem operátora. Kdokoli nabízí 'obnovení' fráze, nabízí její uhodnutí.

Expozice vyžaduje jinou reakci. Opětovné šifrování stejného klíče novou frází ponechá materiál klíče beze změny, takže kopie, která už byla jinde odemčena, stále funguje. Opravou je odvolat nebo nahradit přihlašovací údaj: vydat nový klíč a certifikát, distribuovat je a vyřadit starý u protějšku. Dokud se to nestane, změna hesla souboru je úklid, ne omezení. Starý soubor držte mimo zálohy až poté, co je potvrzeno, že nová identita funguje, a zaznamenejte, které sériové číslo nebo otisk ji nahradil.