Egy HTTPS-proxy két TLS-kapcsolatot jelent, nem egyet

A HTTPS-proxy címke csak az ügyfél és a proxy közötti átvitelt írja le, és semmi mást. Nem mondja, hogy a mögötte lévő webhely ugyanazzal a kapcsolattal titkosított, és nem mondja, hogy a proxy olvashatja az oldalt. Amint szétválasztja a két kapcsolatot, a tanúsítványhibák megszűnnek rejtélyesnek lenni, és a VPN-nel való összehasonlítás kézzelfoghatóvá válik.

Két végpontpár, két ellenőrzés

Közönséges alagútmódban két TLS-kapcsolat van. Az első az ügyféltől a proxyig tart, és hitelesíti a proxyt. A második az ügyféltől az alagúton belüli webhelyig tart, és hitelesíti a webhelyet. Egymástól függetlenül hibáznak, és egymástól függetlenül konfigurálhatók.

Külön bizalmi döntéseik, külön tanúsítványláncaik és külön hibaüzeneteik vannak. Egy szervezeti CA-t használó proxy és egy nyilvános láncot használó nyilvános webhely jogosan igényelhet eltérő ellenőrzési konfigurációt, és ez nem hibás konfiguráció.

Tekintse őket két kapcsolatnak, amelyek véletlenül egy socketet osztanak meg, mert valójában azok.

Mit alagutazik valójában a CONNECT

Az ügyfél CONNECT-kérést küld a hoszt és a port megnevezésével, a proxy pedig TCP-kapcsolatot nyit ahhoz a célhoz. Miután a proxy válaszol, a következő bájtok értelmezés nélkül továbbítódnak, ezért a webhely TLS-kézfogása érintetlenül halad át a proxyn. Így a proxy megtudja a cél nevét és a kapcsolat metaadatait, de nem kap visszafejtett oldalakat ebből az elrendezésből.

Ez a különbségtétel az alagútmód teljes biztonsági érve, és egyben a határa is.

A proxyugráson TLS nélküli HTTP-proxy továbbra is visz át HTTPS-webhelyet a CONNECT-en keresztül. Az ügyfél és a proxy közötti csere nyílt, a webhely kapcsolata viszont nem, és az egészet HTTPS-proxynak nevezni elrejti ezt a különbséget.

Melyik tanúsítvány hibázott

Ha az ellenőrzés meghiúsul, olvassa el a hibában megnevezett végpontot, mielőtt bármilyen bizalmi beállítást módosít. A két hiba hasonlónak tűnik a terminálban, és teljesen eltérő javításokra mutat, ezért az első kérdés mindig az, melyik kapcsolat utasította el.

A curl éppen ezért választja szét a beállításokat. A proxy CA-fájlja a proxy ellenőrzését konfigurálja, míg a CA-fájl a szerver ellenőrzését, és az alkalmazandó bizalmi tároló viselkedése is attól függ, hogyan épült a curl.

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

Egy ellenőrzés elnyomása nem javítás. Semmit nem bizonyít egyik végpontról sem.

A vizsgálat más elrendezés

A TLS-vizsgálat nem alagutazás. Egy vizsgáló közvetítő lezárja a webhely felé irányuló bizalmi kapcsolatot, és saját tanúsítványát mutatja be az ügyfélnek, így az ügyfél a közvetítőt ellenőrzi a webhely helyett. Ez jóváhagyott tervezés mellett jogszerű lehet, és lényegesen más állítás, mint a bájtról bájtra történő továbbítás. Ne feltételezze, hogy minden proxy vizsgál, és ne feltételezze, hogy a titkosított proxyugrás ezt kizárja.

A bizalmi tárolójában lévő szervezeti CA arra utal, melyik elrendezésben van, nem bizonyíték. Kérdezze meg a tervezést, ahelyett hogy tanúsítványláncból következtetne rá.

Ez a két elrendezés különböző választ ad arra a kérdésre, ki olvashatja az oldalt.

Hasonlítsa össze a proxyt és a VPN-t ugyanazon a négy soron

Az összehasonlítás csak akkor lesz hasznos, ha mindkét telepítést ugyanúgy írjuk le.

Az egyetlen kérésre konfigurált proxy azt az egy kérést fedi le. Nem küldi át magán az eszköz minden folyamatát, és a példaparancs pontosan ilyen szűk. A VPN lefedettsége az útválasztásától és alkalmazáspolitikájától függ, amelyeket szintén vizsgálni kell, nem feltételezni. Egyik lehetőség sem fed le mindent csak azért, mert telepítették.

Írja fel a négy sort minden lehetőséghez, és az érv általában magától megoldódik. A hasznos összehasonlítás nem az, melyik címke hangzik titkosítottabbnak. Hanem az, mely szegmensek védettek, kit hitelesítenek a végeiken, mely közvetítőkben bízik, és milyen forgalmat fed le a szabályzat valójában.