HTTPS proxy znamená dvě TLS spojení, ne jedno

Označení HTTPS proxy popisuje pouze přenos mezi vaším klientem a proxy, a nic víc. Neříká, že web za ním je šifrován stejným spojením, ani že proxy může číst stránku. Jakmile dvě spojení oddělíte, chyby certifikátů přestanou být záhadné a srovnání s VPN se stane konkrétním.

Dva páry koncových bodů, dvě ověření

V běžném tunelovém režimu existují dva vztahy TLS. První vede z vašeho klienta k proxy a ověřuje proxy. Druhý vede z vašeho klienta k webu uvnitř tunelu a ověřuje web. Selhávají nezávisle a konfigurují se nezávisle.

Mají oddělená rozhodnutí o důvěře, oddělené řetězce certifikátů a oddělené chybové zprávy. Proxy s organizační CA a veřejný web s veřejným řetězcem mohou legitimně potřebovat jinou konfiguraci ověřování, a to není chybná konfigurace.

Berte je jako dvě spojení, která náhodou sdílejí jeden socket, protože to tak je.

Co CONNECT skutečně tuneluje

Klient odešle požadavek CONNECT s názvem hostitele a portem a proxy otevře TCP spojení k tomuto cíli. Poté, co proxy odpoví, jsou následující bajty přenášeny bez interpretace, proto TLS handshake webu prochází proxy nedotčen. Proxy se tak dozví název cíle a metadata spojení, ale z tohoto uspořádání nedostává dešifrované stránky.

Tento rozdíl je celý bezpečnostní argument tunelového režimu a zároveň jeho hranice.

HTTP proxy bez TLS na přeskoku proxy stále přenáší HTTPS web přes CONNECT. Výměna klient-proxy je otevřená, zatímco spojení s webem není, a nazývat celou věc HTTPS proxy tuto skutečnost skrývá.

Který certifikát selhal

Když ověření selže, přečtěte si koncový bod uvedený v chybě, než změníte jakékoli nastavení důvěry. Obě chyby vypadají v terminálu podobně a ukazují na zcela různé opravy, proto je první otázkou vždy, které spojení odmítlo.

curl odděluje volby právě z tohoto důvodu. Soubor CA proxy konfiguruje ověření proxy, zatímco soubor CA konfiguruje ověření serveru, a chování příslušného úložiště důvěry také závisí na tom, jak byl curl sestaven.

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

Potlačení kontroly není oprava. Nic nedokazuje o žádném z obou koncových bodů.

Inspekce je jiné uspořádání

TLS inspekce není tunelování. Inspekční prostředník ukončuje vztah důvěry směrem k webu a klientovi předkládá vlastní certifikát, takže klient ověřuje prostředníka, nikoli web. To může být legitimní podle schváleného návrhu, ale je to podstatně jiné tvrzení než přenos bajt po bajtu. Nepředpokládejte, že každá proxy provádí inspekci, a nepředpokládejte, že šifrovaný přeskok proxy to vylučuje.

Organizační CA ve vašem úložišti důvěry je náznakem, v jakém uspořádání jste, ne důkazem. Ptejte se na návrh, místo abyste ho odvozovali z řetězce certifikátů.

Tato dvě uspořádání dávají různé odpovědi na otázku, kdo může stránku číst.

Porovnejte proxy a VPN na stejných čtyřech řádcích

Srovnání se stane užitečným, teprve když jsou obě nasazení popsána stejně.

Proxy nakonfigurovaná pro jeden požadavek pokrývá tento požadavek. Neposílá přes sebe každý proces v zařízení a ukázkový příkaz je přesně tak úzký. Pokrytí VPN závisí na jejím směrování a politice aplikací, což je také třeba ověřit, ne předpokládat. Ani jedna možnost nepokrývá vše jen proto, že byla nainstalována.

Napište čtyři řádky pro každou možnost a argument se obvykle vyřeší sám. Užitečné srovnání není, která značka zní šifrovaněji. Je to, které segmenty jsou chráněny, kdo je ověřen na jejich koncích, kterým prostředníkům věříte a jaký provoz politika skutečně zahrnuje.