HTTPS proxy znamená dve TLS spojenia, nie jedno

Označenie HTTPS proxy opisuje iba prenos medzi vaším klientom a proxy a nič viac. Nehovorí, že webová stránka za ním je šifrovaná tým istým spojením, ani že proxy môže čítať stránku. Keď dve spojenia oddelíte, chyby certifikátov prestanú byť záhadné a porovnanie s VPN sa stane konkrétnym.

Dve dvojice koncových bodov, dve overenia

V bežnom tunelovom režime existujú dva vzťahy TLS. Prvý ide z vášho klienta k proxy a overuje proxy. Druhý ide z vášho klienta k webovej stránke vnútri tunela a overuje webovú stránku. Zlyhávajú nezávisle a konfigurujú sa nezávisle.

Majú oddelené rozhodnutia o dôvere, oddelené reťazce certifikátov a oddelené chybové hlásenia. Proxy s organizačnou CA a verejná webová stránka s verejným reťazcom môžu legitímne potrebovať odlišnú konfiguráciu overovania, a to nie je nesprávna konfigurácia.

Berte ich ako dve spojenia, ktoré náhodou zdieľajú jeden socket, pretože to tak je.

Čo CONNECT skutočne tuneluje

Klient odošle požiadavku CONNECT s názvom hostiteľa a portu a proxy otvorí TCP spojenie k tomuto cieľu. Po odpovedi proxy sú nasledujúce bajty prenášané bez interpretácie, preto TLS handshake webovej stránky prechádza cez proxy nedotknutý. Proxy sa tak dozvie názov cieľa a metadáta spojenia a z tohto usporiadania nedostáva dešifrované stránky.

Tento rozdiel je celý bezpečnostný argument tunelového režimu a zároveň jeho hranica.

HTTP proxy bez TLS na skoku proxy stále prenáša HTTPS webovú stránku cez CONNECT. Výmena medzi klientom a proxy je otvorená, kým spojenie s webovou stránkou nie, a nazývať celú vec HTTPS proxy tento rozdiel skrýva.

Ktorý certifikát zlyhal

Keď overenie zlyhá, prečítajte si koncový bod uvedený v chybe, skôr než zmeníte akékoľvek nastavenie dôvery. Obe chyby vyzerajú v termináli podobne a ukazujú na úplne odlišné opravy, preto je prvou otázkou vždy, ktoré spojenie odmietlo.

curl oddeľuje možnosti práve z tohto dôvodu. Súbor CA proxy konfiguruje overenie proxy, kým súbor CA konfiguruje overenie servera, a správanie príslušného úložiska dôvery tiež závisí od toho, ako bol curl zostavený.

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

Potlačenie kontroly nie je oprava. Nič nedokazuje o žiadnom z dvoch koncových bodov.

Inšpekcia je iné usporiadanie

TLS inšpekcia nie je tunelovanie. Inšpekčný sprostredkovateľ ukončuje vzťah dôvery voči webovej stránke a klientovi predkladá vlastný certifikát, takže klient overuje sprostredkovateľa, nie stránku. To môže byť legitímne podľa schváleného návrhu a je to podstatne iné tvrdenie než prenos bajt po bajte. Nepredpokladajte, že každá proxy vykonáva inšpekciu, a nepredpokladajte, že šifrovaný skok proxy to vylučuje.

Organizačná CA vo vašom úložisku dôvery je náznakom, v akom usporiadaní sa nachádzate, nie dôkazom. Pýtajte sa na návrh, namiesto toho, aby ste ho odvodzovali z reťazca certifikátov.

Tieto dve usporiadania dávajú rôzne odpovede na otázku, kto môže čítať stránku.

Porovnajte proxy a VPN na rovnakých štyroch riadkoch

Porovnanie sa stane užitočným, až keď sú obe nasadenia opísané rovnakým spôsobom.

Proxy nakonfigurovaná pre jednu požiadavku pokrýva túto požiadavku. Neposiela cez seba každý proces v zariadení a ukážkový príkaz je presne taký úzky. Pokrytie VPN závisí od jej smerovania a politiky aplikácií, ktoré je tiež potrebné overiť, nie predpokladať. Ani jedna možnosť nepokrýva všetko len preto, že bola nainštalovaná.

Napíšte štyri riadky pre každú možnosť a argument sa zvyčajne vyrieši sám. Užitočné porovnanie nie je, ktorá značka znie šifrovanejšie. Ale ktoré segmenty sú chránené, kto je overený na ich koncoch, ktorým sprostredkovateľom dôverujete a akú prevádzku politika skutočne zahŕňa.