Připínání TLS a vstup přes VPN odpovídají na různé otázky

Postavte soukromou mobilní aplikaci za VPN a rozumný člověk se zeptá, zda ještě potřebuje připínání certifikátů. Otázka zní jako volba mezi dvěma rovnocennými kontrolami, a přitom je to otázka o dvou různých branách. VPN rozhoduje, zda toto zařízení smí cestu vůbec použít; aplikace rozhoduje, zda server, kterého dosáhla, je ten, který očekávala. Odpovězte na obojí odděleně a návrh se zjednoduší.

Dvě brány, dvě otázky

Vstup do sítě se týká klienta: je toto zařízení zapsané, je jeho pověření platné a dovoluje mu politika tuto cestu? Důvěra aplikace se týká serveru: dosáhlo spojení služby s identitou, kterou aplikace přijímá? Tyto odpovědi přicházejí z různých systémů, selhávají z různých důvodů a opravují je různé týmy. VPN handshake může uspět, zatímco aplikace mluví s propadlým certifikátem za protějškem. Dokonale připnutá aplikace může zůstat nedostupná pro kohokoli, protože zařízení se na síť vůbec nedostalo.

Obě se sčítají. Vypuštění kteréhokoli odebere kontrolu; přidání jednoho nenahrazuje druhé.

Co připínání skutečně omezuje

Připínání zužuje množinu identit serveru, které aplikace přijme, obvykle pojmenováním veřejného klíče nebo hashe certifikátu místo důvěry v každý řetěz, za který by nějaké úložiště ručilo. Je to omezení navrstvené na běžné ověření, ne jeho náhrada. Běžné ověření odpovídá, zda je řetěz vůbec důvěryhodný; připínání odpovídá, zda je to řetěz, který tato aplikace očekává. Implementace, která první krok přeskočí, nezískala bezpečnost, jen novost.

Připínaný objekt se mezi platformami liší, takže samotné slovo říká jen velmi málo. Zkopírovat hash z úložiště důvěry jednoho produktu a považovat ho v mobilní aplikaci za totéž je častá a tichá chyba.

Připínání na platformě je konfigurace, ne politika

Android vystavuje připínání přes svou konfiguraci zabezpečení sítě, kde sada připnutí drží otisky veřejného klíče a řetěz musí obsahovat alespoň jeden z nich. Tento soubor je pro každou aplikaci a vyžaduje záměrnou změnu buildu. iOS nemá ekvivalentní mechanismus manifestu, takže připínání tam žije ve vlastním kódu aplikace pro vyhodnocení důvěry.

Protože se mechanismus liší, požadavek se musí psát pro každou platformu. Politika, která říká připni certifikát, aniž by pojmenovala platformu, není proveditelná.

Rotace rozhoduje, zda připínání přežije

Těžká část není první vydání, ale obnova certifikátu po něm. Restriktivní politika důvěry odmítá legitimní nový klíč stejně pevně jako útočníkův.

Dva mechanismy činí rotaci přežitelnou: záložní připnutí, kterému se věří dřív, než je potřeba, a datum vypršení na sadě připnutí, aby vynucení skončilo, místo aby aplikaci zablokovalo. Obojí jsou politická rozhodnutí a vypršení je zejména záměrné snížení bezpečnosti, ne neškodný časovač. Pojmenujte, kdo řídí build aplikace, koncový bod TLS a obnovu certifikátu, a spojte je do jednoho procesu změny. Pokud jsou to tři různé týmy, připínání nakonec způsobí výpadek, který nikdo nenaplánoval.

Ztracené zařízení je třetí problém

Odvolání pověření VPN nutně neukončí relaci aplikace a připnutí serveru nedělá vůbec nic s telefonem v cizí ruce. Zámek zařízení, úložiště pověření, životnost relace a vzdálené odvolání jsou samostatná rozhodnutí se samostatnými vlastníky. Složit je do debaty o připínání zaručí, že se žádné z nich nenavrhne.

Testujte čtyři vztahy místo toho jednoho, který vidíte: zamýšlený server a operaci, účet, který má být odmítnut, identitu serveru, která má být zavržena, a plánovanou rotaci. Fungující VPN procvičí jen první. Zapište, co každý test prokázal, protože další člověk bude předpokládat, že zelený tunel znamená, že prošly všechny čtyři.