OpenVPN bez CA: jak peer-fingerprint ověřuje protějšky
Otisk připíná jeden certifikát, nikoli sdílené tajemství. Sledujte, co digest pokrývá, jak si každá strana staví seznam povolených a co stojí obnova.
Malé nasazení sahá po otiscích, protože certifikační autorita vypadá jako infrastruktura, na kterou nemá nikdo čas. Instinkt je rozumný, ale zkratka, kterou lidé místo toho volí—kopírování jednoho tajemství datového kanálu na oba konce—ne. Nastavení peer-fingerprint zachovává strukturu TLS nedotčenou: každá strana stále drží svůj soukromý klíč a certifikát a každá strana stále ověřuje tu druhou. Mění se to, kde je ověření ukotveno: od důvěryhodného vydavatele ke krátkému seznamu připnutých digestů. Protože digest pokrývá celý certifikát, ne jméno, stává se obnova operací, která skutečně bere čas.
K čemu se otisk vlastně zavazuje
Otisk certifikátu je digest celého certifikátu v kódování DER, ne jeho veřejného klíče a ne jména jeho subjektu. Proto dva certifikáty se stejnými jmény a stejným klíčem, ale různými daty platnosti mají různé otisky. To dělá připínání přesným a to také dělá obnovu rušivou. Připnutí nemůže znamenat důvěru v klíč obecně, protože pojmenovává jeden artefakt v jednom okamžiku jeho života. Digest může znát kdokoli a samotná znalost nic nedokazuje.
openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256Vlastnictví odpovídajícího soukromého klíče je to, co dokazuje, že protějšek drží tento certifikát, a digest je způsob, jakým se druhá strana rozhoduje, zda tento certifikát vůbec očekávala. Toto oddělení je důvod, proč tento návrh není staré uspořádání se sdíleným tajemstvím: sdílený klíč autentizuje každého, kdo zná stejné bajty, zatímco připnutí autentizuje jeden certifikát. Jiné zařízení dostane vlastní záznam místo kopie stejného tajemství, což je malý rozdíl v souborech a velký v rozsahu škody.
Mapa je vzájemná, ne symetrická
Každý konec potřebuje dvě věci: svůj soukromý klíč s certifikátem a prohlášení o tom, které certifikáty protějšků přijme. U klienta je tím prohlášením digest certifikátu serveru; u serveru je to seznam digestů zapsaných klientů. Oficiální příklad pro malé nastavení pro Community 2.6 ukazuje uspořádání s peer-fingerprint a stojí za přečtení, než pro skutečné nasazení zvolíte tento model důvěry. Dva směry nejsou jeden obrácený seznam a neselhávají ve stejný okamžik.
| Verification direction | What is pinned | What never leaves that endpoint | How a wrong pin shows up |
|---|---|---|---|
| Client checks the server | One digest, for the server certificate | The server private key | The client aborts during the TLS handshake |
| Server checks the client | A digest per enrolled client | Each client private key | The server rejects the peer before a tunnel exists |
Přidání zařízení upravuje seznam povolených na serveru, bez kopírování soukromého materiálu existujícího klienta a bez přesouvání klíče serveru kamkoli. Dva směry také selhávají nezávisle, což je užitečné při diagnostice: strana, která uzavře handshake, je strana, jejíž očekávání nebylo splněno. Pokud klient odmítne server, digest neodpovídá předloženému certifikátu. Pokud server odmítne klienta, digest toho klienta v seznamu chybí, nebo klient předkládá jiný certifikát, než který byl zapsán.
Zápis: jak se nové zařízení připojí
Vygenerujte klíč a certifikát nového zařízení tam, kde bude soukromý klíč žít, a poté přesuňte pouze veřejný artefakt straně, která ho má připnout. Přeneste očekávaný digest kanálem, kterému už důvěřujete, a porovnejte celý certifikát místo jména, které vypadá povědomě. Digest zkopírovaný ze stejného neověřeného stažení jako certifikát dokazuje jen to, že se oba soubory shodují. To je kontrola konzistence, ne identity, a je to nejtišší způsob, jak tento návrh slábne.
Na serveru je přidání digestu změnou konfigurace, která prochází běžným správcem a následuje po ní opětovné připojení. Potvrďte, že se nové zařízení připojí a že zařízení, jehož digest byl odstraněn, se už nepřipojí. Test, který pokrývá jen pozitivní případ, nechává seznam povolených neověřený, což je přesně stav, ve kterém budete za šest měsíců.
Obnova je drahý okamžik
Každý certifikát vyprší a nový certifikát má nový digest, i když klíč a jména zůstanou stejné. Pod vydavatelem je obnova průhledná pro protějšky, které tomu vydavateli důvěřují; pod připnutím je to událost zápisu pro každý protějšek, který certifikát připíná.
Naplánujte pořadí před datem vypršení, ne po něm. Rozdělte nový digest stranám, které ho ověřují, použijte změnu a teprve potom vyměňte certifikát na konci. Toto pořadí nenechává žádné okno, ve kterém se obě strany neshodnou, který certifikát je aktuální. Udržujte pod dohledem i samotný seznam, protože připnutý seznam hromadí záznamy zařízení vyřazených před měsíci. Každý zastaralý záznam je identita, která se stále autentizuje, pokud její klíč přežije, takže odstranění jednoho je bezpečnostní akce, ne uklízení.
Co mapa důvěry nerozhoduje
Autentizace je jedna vrstva a připnutá mapa neříká nic o fondu adres, protlačovaných trasách, MTU cesty ani politice firewallu. Ty zůstávají samostatnou konfigurací se samostatnými režimy selhání. Tunel, který se autentizuje a nepropouští žádný provoz, je jiné vyšetřování než ten, který se nikdy nezvedne.
Mapa se také neškáluje neomezeně a PKI založená na vydavateli je místo, kam dospějí větší nasazení. Ta preference je o provozu, ne o kryptografii, protože přidávat a vyřazovat identity přes jednu autoritu je levnější než upravovat seznam u každého protějšku, jak flotila roste. Kde klientská implementace tuto volbu nepodporuje, odpovědí je kompatibilní model důvěry, který ten klient dokumentuje, nebo podporovaná náhrada. Potlačení varování ověření tuto podporu nepřidá a celá hodnota návrhu je, že ověření stále probíhá.