tls-auth a tls-crypt: co každá z voleb v OpenVPN chrání
tls-auth podepisuje řídicí pakety, tls-crypt je navíc skrývá. Ani jedna nenahrazuje ověření certifikátů ani šifru dat a neshoda vypadá jako ticho.
Obě volby používají společný soubor s klíčem a obě ztěžují padělání provozu handshake, proto se s nimi zachází jako se dvěma názvy téže funkce. Nejsou. Jedna podepisuje řídicí pakety, druhá je navíc šifruje, a ani jedna nemá nic společného se šifrou, která chrání váš obsah.
Tento rozdíl je důležitý, když se profil nemůže připojit, když se bezpečnostní audit ptá, co klíč chrání, a když někdo předpokládá, že soubor navíc činí tunel šifrovaným nějakým blíže neurčeným způsobem.
Co společný klíč skutečně chrání
Klíč, který tyto volby používají, patří řídicímu kanálu: výměně, která vyjednává parametry, prokazuje identity a odvozuje klíče dat. Je to předem sdílené tajemství, které musí mít oba konce, než může handshake pokračovat. Protože stojí před ověřením identity, špatný klíč zastaví rozhovor dřív, než by to udělalo špatné heslo. Toto pořadí vysvětluje, proč je režim selhání tak tichý.
tls-auth používá toto tajemství k výpočtu HMAC nad řídicími pakety. Paket bez platného podpisu se zahodí dřív, než se dostane k dražšímu zpracování TLS, a proto se tato volba často popisuje jako první filtr, nikoli jako náhrada TLS.
tls-crypt jde dál a chráněný řídicí provoz kromě ověření také šifruje. Obsah certifikátů, vyjednané názvy šifer a další podrobnosti handshake už nejsou v síti vidět a pozorovatel bez klíče nevidí ani to, která verze TLS se zkouší. Pro nasazení, které se obává prozrazení svého otisku VPN, je tato vlastnost hlavním důvodem, proč ji zvolit. Pořád je to skupinové tajemství, ne pověření pro jednotlivého uživatele.
Ani jeden mechanismus nevydává identity. Společný klíč je skupinové tajemství a každý, kdo ho má, může tuto vrstvu kontroly splnit.
V čem se obě volby liší
Pozorovatelný rozdíl je v tom, co pozorovatel vidí. S tls-auth je handshake viditelný, ale bez klíče neověřitelný. S tls-crypt je handshake neprůhledný pro každého, kdo klíč nemá.
Liší se i konfigurace. tls-auth se používá s hodnotou směru, takže jedna strana používá jednu polovinu klíčového materiálu a druhá strana druhou polovinu. tls-crypt používá jeden klíč v obou směrech, takže direktiva směru k jeho uspořádání nepatří.
V moderních verzích se obě volby vzájemně vylučují. Profil má nést jednu z nich, ne obě, a server s klientem se musí shodnout, kterou, se shodným klíčovým materiálem. Ponechání staré direktivy vedle nové je častý zbytek po migraci. Odstraňte tu neaktivní, aby další čtenář věděl, která vrstva skutečně platí.
Novější varianta, tls-crypt-v2, váže každého klienta k jeho vlastnímu zabalenému klíči, takže odebrání jednoho klienta nevyžaduje znovu vydat skupinový klíč. Stojí za to o ní vědět, ale je to jiná volba a není synonymem ani jedné z těch dvou zde.
Proč neshoda vypadá, jako by se nic nedělo
Když se sdílený materiál neshoduje, protistrana pakety zahodí, aniž by odesílateli řekla proč. Není k přečtení žádná chyba ověření, protože paket nikdy nedorazil do vrstvy, která by ji vytvořila.
Klient to zkouší znovu, server nic neříká a příznak vypadá jako problém sítě. Lidé pak restartují službu, znovu opisují heslo k účtu nebo odstraní ochrannou direktivu, aby ji «otestovali», což nasazení mění, místo aby ho diagnostikovalo.
Čtěte v logu serveru první stížnost na úrovni paketu, ne poslední řádek opakovaného pokusu. Ověřte, že obě strany nesou stejnou volbu se shodným klíčovým materiálem a že klíčový soubor nebyl znovu vygenerován jen na jedné straně.
Odstranění direktivy není bezpečná oprava. Vypíná vrstvu ochrany pro každého klienta a tunel, který pak funguje, dokazuje jen to, že ona vrstva byla tou neshodou.
Co je ještě třeba nastavit zvlášť
Tyto volby neověřují, kdo je protistrana. Ověření certifikátů, důvěryhodný kořen a očekávaný název serveru zůstávají samostatnými požadavky a žádný z nich se nestává nepovinným kvůli přítomnosti společného klíče.
Také nevolí šifru dat. To je samostatné vyjednávání, které řídí nastavení datového kanálu na obou stranách, a tunel chráněný pomocí tls-crypt může i tak použít šifru, kterou jste nezamýšleli.
Nakonec si péči žádá sám společný klíč. Chovejte se k němu jako k tajemství, distribuujte ho schváleným kanálem a vyměňte ho, když odejde kdokoli, kdo ho měl. Protože je sdílený, jeho prozrazení je prozrazením každého koncového bodu, který ho používá.