HTTPS-puhverserver tähendab kahte TLS-ühendust, mitte ühte

Silt HTTPS-puhverserver kirjeldab ainult transporti teie kliendi ja puhverserveri vahel ega midagi enamat. See ei ütle, et selle taga olev veebisait on sama ühendusega krüpteeritud, ega ütle, et puhverserver saab lehte lugeda. Kui eraldate kaks ühendust, lakkavad sertifikaadivead olemast mõistatuslikud ja võrdlus VPN-iga muutub konkreetseks.

Kaks otspunktipaari, kaks kontrolli

Tavalises tunnelirežiimis on kaks TLS-suhit. Esimene kulgeb teie kliendist puhverserverini ja autendib puhverserveri. Teine kulgeb teie kliendist tunnelis oleva veebisaidini ja autendib veebisaidi. Need ebaõnnestuvad sõltumatult ja neid konfigureeritakse sõltumatult.

Neil on eraldi usaldusotsused, eraldi sertifikaadiahelad ja eraldi veateated. Organisatsioonilist CA-d kasutav puhverserver ja avalikku ahelat kasutav avalik veebisait võivad õigustatult vajada erinevat kontrollikonfiguratsiooni ja see ei ole vale konfiguratsioon.

Käsitlege neid kahe ühendusena, mis juhtumisi jagavad ühte socketit, sest seda need ongi.

Mida CONNECT tegelikult tunnelib

Klient saadab CONNECT-päringu, milles nimetab hosti ja pordi, ning puhverserver avab TCP-ühenduse selle sihtmärgini. Pärast puhverserveri vastust edastatakse järgnevad baidid ilma tõlgendamiseta, seepärast läbib veebisaidi TLS-kätlus puhverserverit puutumatult. Nii saab puhverserver teada sihtkoha nime ja ühenduse metaandmed, kuid ei saa sellest korraldusest dekrüpteeritud lehti.

See erinevus on kogu tunnelirežiimi turvaargument ja ühtlasi selle piir.

HTTP-puhverserver ilma TLS-ita puhverserveri hüppel kannab ikkagi HTTPS-veebisaiti läbi CONNECT-i. Kliendi ja puhverserveri vaheline suhtlus on avatud, samas kui veebisaidi ühendus ei ole, ja kogu asja HTTPS-puhverserveriks nimetamine varjab selle erinevuse.

Milline sertifikaat ebaõnnestus

Kui kontroll ebaõnnestub, lugege veateates nimetatud otspunkti enne mis tahes usaldusseade muutmist. Kaks ebaõnnestumist näevad terminalis sarnased välja ja osutavad täiesti erinevatele parandustele, seepärast on esimene küsimus alati, milline ühendus keeldus.

curl eraldab valikud täpselt sel põhjusel. Puhverserveri CA-fail konfigureerib puhverserveri kontrolli, samas kui CA-fail konfigureerib serveri kontrolli, ja kohaldatava usaldushoidla käitumine sõltub ka sellest, kuidas curl ehitati.

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

Kontrolli summutamine ei ole parandus. See ei tõesta midagi kummagi otspunkti kohta.

Inspekteerimine on teistsugune korraldus

TLS-inspekteerimine ei ole tunnelimine. Inspekteeriv vahendaja lõpetab veebisaidi suunas usaldussuhte ja esitab kliendile oma sertifikaadi, seega klient kontrollib vahendajat, mitte saiti. See võib olla õigustatud kinnitatud disaini korral, kuid on sisuliselt teistsugune väide kui bait-baidilt edastamine. Ärge eeldage, et iga puhverserver inspekteerib, ja ärge eeldage, et krüpteeritud puhverserveri hüpe seda välistab.

Organisatsiooniline CA teie usaldushoidlas on vihje selle kohta, millises korralduses olete, mitte tõestus. Küsige disaini, selle asemel et tuletada seda sertifikaadiahelast.

Need kaks korraldust annavad erinevaid vastuseid küsimusele, kes saab lehte lugeda.

Võrrelge puhverserverit ja VPN-i samal neljal real

Võrdlus muutub kasulikuks alles siis, kui mõlemat juurutust kirjeldatakse ühtemoodi.

Ühe päringu jaoks konfigureeritud puhverserver katab selle päringu. See ei suuna seadme iga protsessi endast läbi ja näidiskäsk on täpselt nii kitsas. VPN-i katvus sõltub selle marsruutimisest ja rakendusepoliitikast, mida tuleb samuti kontrollida, mitte eeldada. Kumbki valik ei kata kõike lihtsalt sellepärast, et see paigaldati.

Kirjutage iga valiku jaoks neli rida ja vaidlus laheneb tavaliselt iseenesest. Kasulik võrdlus ei ole see, milline silt kõlab krüpteeritumalt. Vaid see, millised segmendid on kaitstud, kes nende otstes kinnitatakse, milliseid vahendajaid te usaldate ja millist liiklust poliitika tegelikult hõlmab.