Vlastní certifikát VPN není další šifrovací vrstva
Certifikát mění identitu a důvěru, ne počet šifrovacích vrstev. Rozhodněte se podle otázky, co a kde končí.
Instalace vlastního certifikátu na VPN endpoint působí jako přidání ochrany, protože certifikáty a šifrování se všude objevují společně. V praxi to mění dvě věci: jakou identitu endpoint představuje a kterému vydavateli je jeho protějšek ochoten věřit. Ani jedno z toho nezabalí vaše data podruhé. Pokud je skutečnou potřebou druhý chráněný kanál, potřebujete druhý kanál s vlastními endpointy, ne další certifikát.
Tři oddělené úlohy v handshake TLS 1.3
RFC 8446 tyto věci odděluje a právě to oddělení je celá odpověď. Zpráva Certificate nese řetězec certifikátů endpointu. CertificateVerify prokazuje držení odpovídajícího soukromého klíče a váže přepis handshake. Záznamová vrstva chrání provoz pomocí vyjednaných provozních klíčů.
Vyměňte certifikát a první dvě položky se změní. Ochrana záznamů neběží dvakrát a nezesílí jen proto, že je vydavatel nyní soukromý.
Co soukromá CA skutečně přináší
Přináší řízený systém identity: vy rozhodujete, komu se vydává, vy rozhodujete, které vydavatele protějšky přijímají, a můžete odvolávat podle svého plánu. To je opravdu užitečné, když spravujete oba konce.
Přináší ale i povinnosti. Důvěru je třeba šířit záměrně, ověřování protějšku musí zůstat zapnuté a životní cyklus přihlašovacích údajů musí někdo vlastnit. Soukromá CA není zkratkou kolem žádné z těch tří věcí.
Kdy je druhý kanál správnou odpovědí
Představte si aplikaci, která otevírá ověřené HTTPS ke své vlastní službě, zatímco její pakety putují i přes VPN. Takový návrh má dvě hranice s možná odlišnými endpointy, a tak vypadá druhý chráněný kanál.
Rozdíl je důležitý na bráně. Pokud TLS relace aplikace končí na VPN bráně místo v aplikaci, ochrana, o které jste si mysleli, že ji máte za tunelem, tam není. Napište si, kdo ukončuje každý kanál, než toto vlastnictví budete tvrdit.
Zeptejte se, co instalace mění
Žádost o instalaci certifikátu může znamenat tři různé věci. Může změnit vlastní identitu klienta, ukotvení důvěry specifické pro aplikaci nebo důvěru v celé platformě pro vše na zařízení. To není totéž a jen poslední z nich ovlivňuje nesouvisející software.
Zeptejte se, které ze tří je zamýšlené, a pak, čeho má dosáhnout. Pokud je odpovědí více šifrování, návrh míří na špatný mechanismus.
Zapište hranice
U každého kanálu zapište endpointy, identitu, kterou každá strana ověřuje, a co může vidět operátor uprostřed. Potom zapište chování při selhání: co se stane, když ověření selže, a co když je kanál odmítnut.
Dva řádky na jedné stránce obvykle vyřeší spor, který rotace certifikátu vyřešit nedokáže.
Rozhodněte třemi otázkami
Je problém v tom, za koho se endpoint vydává, nebo v tom, co se děje s daty? Musí ochrana pokračovat za VPN bránou ke konkrétní aplikaci? A dokážete pojmenovat dva endpointy, které by ukončily druhý kanál?
Pokud je skutečná první otázka, opravte identitu a důvěru. Pokud druhá nebo třetí, navrhněte druhý kanál a nechte certifikát tam, kam patří.