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ří.

Související články