Proxy HTTPS pomeni dve povezavi TLS, ne ene

Oznaka proxy HTTPS opisuje samo prenos med vašim odjemalcem in proxyjem, in nič več. Ne pravi, da je spletno mesto za njim šifrirano z isto povezavo, niti da lahko proxy prebere stran. Ko ločite povezavi, se napake potrdil nehajo biti skrivnostne in primerjava z VPN postane konkretna.

Dva para končnih točk, dve preverjanji

V običajnem načinu tunela obstajata dve razmerji TLS. Prvo poteka od vašega odjemalca do proxyja in overi proxy. Drugo poteka od vašega odjemalca do spletnega mesta znotraj tunela in overi spletno mesto. Odpovedujeta neodvisno in se konfigurirata neodvisno.

Imata ločene odločitve o zaupanju, ločene verige potrdil in ločena sporočila o napaki. Proxy z organizacijskim CA in javno spletno mesto z javno verigo lahko upravičeno potrebujeta drugačno konfiguracijo preverjanja, in to ni napačna konfiguracija.

Obravnavajte ju kot dve povezavi, ki si slučajno delita eno vtičnico, ker to sta.

Kaj CONNECT dejansko tunelira

Odjemalec pošlje zahtevo CONNECT z imenom gostitelja in vrati, proxy pa odpre povezavo TCP do tega cilja. Potem ko proxy odgovori, se naslednji bajti posredujejo brez interpretacije, zato TLS rokovanje spletnega mesta poteka skozi proxy nedotaknjeno. Tako proxy izve ime cilja in metapodatke povezave, vendar iz te ureditve ne prejme dešifriranih strani.

Ta razlika je celoten varnostni argument načina tunela in hkrati njegova meja.

Proxy HTTP brez TLS na skoku proxy še vedno prenaša spletno mesto HTTPS prek CONNECT. Izmenjava med odjemalcem in proxyjem je v jasnem besedilu, medtem ko povezava s spletnim mestom ni, in če vse skupaj imenujemo proxy HTTPS, ta razlika izgine.

Katero potrdilo je odpovedalo

Ko preverjanje odpove, preberite končno točko, navedeno v napaki, preden spremenite katero koli nastavitev zaupanja. Obe napaki sta v terminalu videti podobni in kažeta na popolnoma različne popravke, zato je prvo vprašanje vedno, katera povezava je zavrnila.

curl ločuje možnosti prav zaradi tega razloga. Datoteka CA proxyja konfigurira preverjanje proxyja, medtem ko datoteka CA konfigurira preverjanje strežnika, na vedenje veljavnega skladišča zaupanja pa vpliva tudi, kako je bil curl zgrajen.

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

Zatiranje preverjanja ni popravilo. Ničesar ne dokazuje o nobeni od obeh končnih točk.

Pregled je drugačna ureditev

Pregled TLS ni tuneliranje. Pregledujoči posrednik konča razmerje zaupanja do spletnega mesta in odjemalcu predstavi lastno potrdilo, zato odjemalec preveri posrednika in ne mesta. To je lahko zakonito v okviru odobrene zasnove in je bistveno drugačna trditev kot posredovanje bajt za bajt. Ne predpostavljajte, da vsak proxy pregleduje, in ne predpostavljajte, da šifriran skok proxyja to izključuje.

Organizacijski CA v vašem skladišču zaupanja je namig, v kateri ureditvi ste, ne dokaz. Vprašajte za zasnovo, namesto da jo sklepate iz verige potrdil.

Ti dve ureditvi dajeta različna odgovora na vprašanje, kdo lahko prebere stran.

Primerjajte proxy in VPN na istih štirih vrsticah

Primerjava postane koristna šele, ko sta obe uvedbi opisani na enak način.

Proxy, konfiguriran za eno zahtevo, pokrije to zahtevo. Ne pošilja vsakega procesa na napravi skozi sebe, in primer ukaza je natanko tako ozek. Pokritost VPN je odvisna od njegovega usmerjanja in politike aplikacij, ki ju je prav tako treba pregledati, ne pa predpostaviti. Nobena možnost ne pokrije vsega samo zato, ker je bila nameščena.

Napišite štiri vrstice za vsako možnost in argument se običajno razreši sam. Koristna primerjava ni, katera oznaka zveni bolj šifrirano. Temveč katere segmente ščiti, kdo je preverjen na njihovih koncih, katerim posrednikom zaupate in kateri promet politika dejansko zajema.