Může řetěz certifikátů serveru přepsat úložiště důvěry klienta?
Úplný řetěz je důkaz, ne příkaz. Ověřování probíhá na klientovi s jeho vlastními kořeny, takže žádný server nemůže vynutit rozhodnutí o důvěře.
Prohlížeč zobrazí upozornění na certifikát u webu, jehož řetěz je úplný, a prvním instinktem je opravit server. Server obvykle předkládá přesně to, co má. Klient rozhoduje, které kořeny přijme, a žádné uspořádání zprostředkujících certifikátů nemůže toto rozhodnutí změnit z druhého konce spojení. Tato hranice vysvětluje většinu toho, co vypadá jako problém s certifikátem.
Ověřování probíhá na klientovi, s kořeny klienta
Ověření cesty vezme předložené certifikáty a sestaví řetěz k důvěryhodnému kořeni, který ověřující systém už má. RFC 5280 tento model popisuje a klade volbu kořene do místní implementace, nikoli do serveru. Aplikace může navrch přidat vlastní politiku: připnutý klíč, podnikové úložiště důvěry, nebo přísnější kontrolu identity. Seznam certifikátů, který server posílá, je důkaz nabídnutý tomuto procesu, nikdy příkaz pro něj.
Úplný řetěz tedy dokazuje, že server má díly. Nedokazuje, že je klient přijme.
Chcete-li vidět, co server skutečně posílá, spusťte openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts a spočítejte certifikáty ve výstupu. Neúplný řetěz tam je oprava na straně serveru. Úplný řetěz přesouvá otázku na klienta a jeho kořeny, kde server nemá hlas.
Co inspekce TLS skutečně mění
Inspekční zařízení ukončí TLS relaci na straně klienta a otevře samostatnou relaci ke skutečné službě. Klient pak ověří certifikát zařízení, který musí vést ke kořeni, jemuž klient důvěřuje. Proto spravovaná zařízení dostávají inspekční kořen přes správu zařízení a proto osobní zařízení bez něj zobrazuje upozornění.
Uspořádání je záměrné a místní. Nic v řetězu původního serveru nemůže donutit nespravovaný prohlížeč přijmout náhradní identitu a nic v něm nebrání spravovanému zařízení, aby tak učinilo.
Ukončení VPN není dešifrování HTTPS
VPN vrstva přenáší pakety mezi klientem a branou. Její odstranění nebo čtení její konfigurace neodhalí uvnitř obsažená data HTTPS.
TLS relace stále běží mezi prohlížečem a webovým serverem, se stejnými pravidly ověřování, pokud ji něco výslovně neukončí. Záměna obou vrstev vede k žádosti, aby správce VPN dodal certifikát, zatímco dotyčný certifikát patří inspekčnímu proxy nebo samotnému webu. Než změníte jakékoli úložiště důvěry, zeptejte se, která komponenta certifikát předkládá.
Nastavte očekávání v komponentě, kterou ovládáte
Pokud provozujete aplikaci i jejího klienta, definujte společně očekávanou identitu služby, přijímané vydavatele a případný požadavek na připnutí nebo autentizaci klienta. Plánujte obnovu a zotavení tak, aby se legitimní změna certifikátu nestala výpadkem. Pokud provozujete jen veřejný server, zdokumentujte, jaké ověřování vyžadujete a která klientská prostředí podporujete. Odeslání preferovaného řetězu necertifikuje cizí zařízení.
U spravovaného vybavení řešte nekompatibilitu přes vlastníky aplikace a sítě. Vypnutí ověřování, přidání nevysvětleného kořene nebo snaha přečkat inspekční politiku nenavazuje zamýšlený vztah stran.
Otestujte výsledek na čistém klientském profilu, ne na stroji, kde už byla přidána výjimka. To je jediná kontrola, která ukáže, co nové zařízení zažije.