HTTPS-proxy þýðir tvær TLS-tengingar, ekki eina

Merkimiðinn HTTPS-proxy lýsir aðeins flutningnum milli biðlarans þíns og proxiesins, og engu öðru. Hann segir ekki að vefsvæðið fyrir aftan sé dulkóðað með sömu tengingu, og segir ekki að proxyið geti lesið síðuna. Þegar þú aðskilur tengingarnar tvær hætta skírteinisvillur að vera ráðgátur og samanburðurinn við VPN verður áþreifanlegur.

Tvö endapunktapör, tvær staðfestingar

Í venjulegri göngustillingu eru tvö TLS-sambönd. Hið fyrra fer frá biðlaranum þínum til proxiesins og staðfestir proxyið. Hið síðara fer frá biðlaranum þínum til vefsvæðisins inni í göngunni og staðfestir vefsvæðið. Þau mistakast óháð og eru stillt óháð.

Þau hafa aðskildar traustsákvarðanir, aðskildar skírteiniskeðjur og aðskilin mistakaskilaboð. Proxy sem notar stofnanaca og opinbert vefsvæði sem notar opna keðju geta löglega þurft mismunandi staðfestingarstillingu, og það er ekki rangstillling.

Meðhöndlaðu þau sem tvær tengingar sem deila tilviljun einni sökkli, því það eru þau.

Hvað CONNECT gönguleggur í raun

Biðlarinn sendir CONNECT-beiðni þar sem hýsill og port eru nefnd, og proxyið opnar TCP-tengingu á þann áfangastað. Eftir að proxyið svarar eru næstu bætin send áfram án túlkunar, þess vegna fer TLS-handaband vefsvæðisins ósnortið gegnum proxyið. Þannig lærir proxyið nafn áfangastaðar og lýsigögn tengingarinnar, og fær ekki afdulkóðaðar síður úr þeirri ráðstöfun.

Sá greinarmunur er öll öryggisrökfræði göngustillingarinnar, og hann er líka mörk hennar.

HTTP-proxy án TLS á proxy-hoppinu flytur samt HTTPS-vefsvæði gegnum CONNECT. Skiptin milli biðlara og proxies fara fram í opnu, en tenging vefsvæðisins gerir það ekki, og að kalla allt saman HTTPS-proxy felur þann mun.

Hvaða skírteini brást

Þegar staðfesting brestur skaltu lesa endapunktinn sem nefndur er í villunni áður en þú breytir einhverri traustsstillingu. Villurnar tvær líta svipað út í skjáhermi og vísa á gjörólíkar lagfæringar, þess vegna er fyrsta spurningin alltaf hvaða tenging hafnaði.

curl aðskilur valkostina einmitt af þessari ástæðu. CA-skrá proxiesins stillir staðfestingu proxiesins, en CA-skráin stillir staðfestingu netþjónsins, og hegðun viðeigandi traustsgeymslu fer líka eftir því hvernig curl var byggt.

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

Að bæla prófun er ekki viðgerð. Það sannar ekkert um hvorn endapunktinn sem er.

Skoðun er önnur ráðstöfun

TLS-skoðun er ekki gönguleiðsla. Skoðandi milliliður lýkur traustssambandinu við vefsvæðið og kynnir eigið skírteini fyrir biðlaranum, svo biðlarinn staðfestir milliliðinn en ekki vefsvæðið. Það getur verið löglegt samkvæmt samþykktri hönnun, og það er efnislega önnur fullyrðing en sending bæta fyrir bæti. Ekki gera ráð fyrir að hvert proxy skoði, og ekki gera ráð fyrir að dulkóðað proxy-hopp útiloki það.

Stofnanaca í traustsgeymslunni þinni er vísbending um hvaða ráðstöfun þú ert í, ekki sönnun. Spurðu um hönnunina í stað þess að álykta hana úr skírteiniskeðju.

Þessar tvær ráðstafanir gefa ólík svör við spurningunni um hver getur lesið síðuna.

Berðu saman proxy og VPN á sömu fjórum línum

Samanburðurinn verður aðeins gagnlegur þegar báðar uppsetningarnar eru lýstar á sama hátt.

Proxy sem er stillt fyrir eina beiðni nær yfir þá beiðni. Það sendir ekki hvert ferli tækisins í gegnum sig, og dæmisipunin er einmitt svona þröng. Umfang VPN fer eftir leiðvörpun þess og forritastefnu, sem einnig þarf að skoða í stað þess að gera ráð fyrir. Hvorugur valkosturinn nær yfir allt eingöngu vegna þess að hann var uppsettur.

Skrifaðu fjórar línur fyrir hvern valkost og röksemdin leysist yfirleitt sjálf. Gagnlegi samanburðurinn er ekki hvor merkið hljómi dulkóðaðra. Heldur hvaða hlutar eru verndaðir, hver er staðfestur á endum þeirra, hvaða milliliðum þú treystir, og hvaða umferð stefnan nær í raun yfir.