Chyby TLS jen na firemní VPN: opravte správné úložiště důvěry
Stejný nástroj, stejný notebook, jen VPN rozbíjí TLS. Přečtěte zprávu, najděte CA svazek, který binárka čte, a přidejte jeden kořen místo vypínání kontrol.
Sestavení Go, instalace Composeru i klient Pythonu doma fungují a všechny selhávají uvnitř firemní VPN. Ten vzorec vám říká o cestě, ne o aplikaci. Něco na tunelu změnilo řetěz certifikátů, který váš proces vidí, nebo zrušilo handshake dřív, než vůbec nějaký řetěz dorazil. Obě poruchy vypadají v terminálu stejně a vyžadují úplně jinou reakci.
Tři zprávy, tři mechanismy
Chyba x509 certificate signed by unknown authority znamená, že řetěz byl sestaven a jeho kořen chybí v úložišti důvěry, které ten proces používá. Chyba self-signed certificate in certificate chain obvykle znamená, že inspekční proxy odpověděla vlastním certifikátem, což je řetěz, který vaše runtime nezná. SSL EOF během handshake znamená, že spojení bylo uzavřeno dřív, než byl odeslán jakýkoli použitelný certifikát, a to je prostřední prvek, který odmítá ClientHello, a vůbec ne problém důvěry.
Přidání přepínače pro nezabezpečený režim způsobí, že všechny tři zprávy zmizí, zatímco odposlech zůstane na místě, a odstraní kontrolu, která by odhalila skutečného útočníka.
Najděte svazek, který proces skutečně čte
Firemní kořen nainstalovaný v úložišti Windows opraví prohlížeče a aplikace .NET, které se dotazují systémového úložiště. Nic neudělá pro sestavení běžící v kontejneru, který si nese vlastní CA svazek, ani pro proces Pythonu s certifi nebo proces Node s vlastním vestavěným seznamem. Go čte systémový fond prostředí, ve kterém binárka běží, tedy kontejneru, ne notebooku. Jeden stroj tak současně dává fungující prohlížeč a selhávající nástroj pro sestavení.
Ptejte se nástroje, místo abyste předpokládali. python3 -c "import ssl; print(ssl.get_default_verify_paths())" vypíše soubory, které Python projde, a node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" ukáže, zda už je nastaveno nějaké přepsání. U kontejneru spusťte stejnou kontrolu uvnitř image, protože to je prostředí, které sestavení skutečně používá.
Nainstalujte jeden kořen tam, kde sestavení běží
Získejte inspekční kořen od IT jako soubor PEM a jeho otisk ověřte odděleným kanálem, než mu začnete věřit. Na image odvozených z Debianu jej zkopírujte do /usr/local/share/ca-certificates/ a spusťte update-ca-certificates; image z rodiny RHEL používají update-ca-trust poté, co soubor umístí do /etc/pki/ca-trust/source/anchors/. Při sestavování kontejneru přidejte tyto kroky před selhávající příkaz, aby se vrstva ukládala do mezipaměti nad instalací závislostí.
Pro místní devcontainer připojte PEM a spouštějte stejný aktualizační příkaz při startu, místo abyste jej pekli do osobního image, který nikdo jiný nezreprodukuje. Nástroje, které si nesou vlastní svazek, potřebují vlastní dokumentované přepsání: pip má nastavení certifikátu, npm má nastavení cafile a většina ostatních přijímá standardní proměnné prostředí.
To není totéž jako přijímat jakýkoli certifikát. Přidáváte jeden konkrétní kořen, získaný od strany provádějící inspekci, do jednoho prostředí a ověřování zůstává zapnuté pro každý jiný řetěz. Poznamenejte, který soubor byl přidán a kdy mu vyprší platnost, protože inspekční kořen se obnovuje jako každý jiný CA.
Když handshake umře dřív než certifikát
Pokud se nic nepředloží, žádná změna úložiště důvěry nepomůže. Porovnejte stejný požadavek s tunelem zapnutým a vypnutým, potom prohlédněte řetěz přímo pomocí openssl s_client -connect host:443 -servername host -showcerts. Spojení, které se mimo VPN dokončí a uvnitř ní se zruší, je politické rozhodnutí prostředního prvku a lékem je výjimka pro tento hostitel, ne další certifikát. Požádejte, aby registr balíčků nebo koncový bod API procházel bez úprav.
Rozdělení tunelu tak, aby nástroj obcházel VPN, se vyhýbá inspekci tohoto provozu, což může porušovat politiku a nástroj nedělá důvěryhodným.
Zapište výsledek pro každý nástroj
Krátká poznámka se seznamem binárky, souboru důvěry, který čte, proměnné prostředí ve hře a schválené výjimky ušetří dalšímu člověku celou diagnostiku. Veďte poznámku pro každý nástroj, ne pro každý notebook, protože notebook je málokdy to, co se změnilo.
A v tiketu držte dvě věty odděleně: nainstalovali jsme konkrétní firemní kořen a vypnuli jsme ověřování. Jen jedna z těch věcí je podpůrná akce.