HTTPS-prokurilo signifas du TLS-ligojn, ne unu

La etikedo HTTPS-prokurilo priskribas nur la transporton inter via kliento kaj la prokurilo, kaj nenion pli. Ĝi ne diras, ke la retejo malantaŭ ĝi estas ĉifrita per tiu sama konekto, nek diras, ke la prokurilo povas legi la paĝon. Kiam vi apartigas la du konektojn, atestilaj eraroj ĉesas esti misteraj kaj la komparo kun VPN iĝas konkreta.

Du finpunktaj paroj, du kontroloj

En ordinara tunela reĝimo ekzistas du TLS-rilatoj. La unua iras de via kliento al la prokurilo kaj aŭtentigas la prokurilon. La dua iras de via kliento al la retejo ene de la tunelo kaj aŭtentigas la retejon. Ili malsukcesas sendepende kaj estas agordataj sendepende.

Ili havas apartajn fiddecidojn, apartajn atestilajn ĉenojn kaj apartajn malsukcesajn mesaĝojn. Prokurilo uzanta organizan CA kaj publika retejo uzanta publikan ĉenon povas laŭleĝe bezoni malsaman kontrolagordon, kaj tio ne estas misagordo.

Traktu ilin kiel du konektojn, kiuj hazarde dividas unu soketon, ĉar tio ili estas.

Kion CONNECT efektive tunelas

La kliento sendas peton CONNECT kun la gastiganto kaj pordo, kaj la prokurilo malfermas TCP-konekton al tiu celo. Post kiam la prokurilo respondas, la sekvaj bajtoj estas plusenditaj sen interpretado, tial la TLS-manpremo de la retejo trapasas la prokurilon netuŝite. Tiel la prokurilo lernas la celan nomon kaj la konektajn metadatenojn, sed ĝi ne ricevas malĉifritajn paĝojn el tiu aranĝo.

Tiu distingo estas la tuta sekureca argumento por tunela reĝimo, kaj ĝi ankaŭ estas ĝia limo.

HTTP-prokurilo sen TLS ĉe la prokura salto ankoraŭ portas HTTPS-retejon tra CONNECT. La interŝanĝo kliento-al-prokurilo estas malkaŝa dum la reteja konekto ne estas, kaj nomi la tuton HTTPS-prokurilo kaŝas tiun diferencon.

Kiu atestilo malsukcesis

Kiam kontrolo malsukcesas, legu la finpunkton nomatan en la eraro antaŭ ol ŝanĝi ajnan fidan agordon. La du malsukcesoj aspektas similaj en terminalo kaj montras al tute malsamaj riparoj, tial la unua demando ĉiam estas, kiu konekto rifuzis.

curl apartigas la opciojn ĝuste pro ĉi tiu kialo. La CA-dosiero de la prokurilo agordas la kontrolon de la prokurilo, dum la CA-dosiero agordas la kontrolon de la servilo, kaj la konduto de la aplikebla fidstokejo ankaŭ dependas de tio, kiel curl estis konstruita.

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

Subpremi kontrolon ne estas riparo. Ĝi pruvas nenion pri iu ajn el la du finpunktoj.

Inspektado estas alia aranĝo

TLS-inspektado ne estas tunelado. Inspektanta peranto finas la fidrilaton al la retejo kaj prezentas sian propran atestilon al la kliento, do la kliento kontrolas la peranton anstataŭ la retejon. Tio povas esti laŭleĝa laŭ aprobita dezajno, kaj ĝi estas substance malsama aserto ol plusendo bajto post bajto. Ne supozu, ke ĉiu prokurilo inspektas, kaj ne supozu, ke ĉifrita prokura salto tion ekskludas.

Organiza CA en via fidstokejo estas aludo pri tio, en kiu aranĝo vi estas, ne pruvo. Demandu pri la dezajno anstataŭ dedukti ĝin el atestila ĉeno.

Tiuj du aranĝoj donas malsamajn respondojn al la demando, kiu povas legi la paĝon.

Komparu prokurilon kaj VPN sur la samaj kvar linioj

La komparo utilas nur tiam, kiam ambaŭ deplojoj estas priskribitaj same.

Prokurilo agordita por unu peto kovras tiun peton. Ĝi ne pasigas ĉiun procezon de la aparato tra si, kaj la ekzempla komando estas ĝuste tiom mallarĝa. La kovrado de VPN dependas de ĝia enkursigado kaj aplikaĵa politiko, kiuj ankaŭ devas esti kontrolitaj anstataŭ supozitaj. Neniu el la du opcioj kovras ĉion simple ĉar ĝi estis instalita.

Skribu la kvar liniojn por ĉiu opcio kaj la argumento kutime solviĝas mem. La utila komparo ne estas, kiu etikedo sonas pli ĉifrita. Sed kiuj segmentoj estas protektitaj, kiu estas kontrolita ĉe iliaj finoj, kiujn perantojn vi fidas, kaj kiun trafikon la politiko efektive inkluzivas.