HTTPS starpniekserveris nozīmē divus TLS savienojumus, ne vienu

Apzīmējums HTTPS starpniekserveris apraksta tikai transportu starp jūsu klientu un starpniekserveri, un neko vairāk. Tas nesaka, ka vietne aiz tā ir šifrēta ar to pašu savienojumu, un nesaka, ka starpniekserveris var lasīt lapu. Tiklīdz jūs atdala abus savienojumus, sertifikātu kļūdas pārstāj būt noslēpumainas un salīdzinājums ar VPN kļūst konkrēts.

Divi galu pāri, divas pārbaudes

Parastā tuneļa režīmā ir divas TLS attiecības. Pirmā iet no jūsu klienta uz starpniekserveri un autentificē starpniekserveri. Otrā iet no jūsu klienta uz vietni tuneļa iekšienē un autentificē vietni. Tās neizdodas neatkarīgi un tiek konfigurētas neatkarīgi.

Tām ir atsevišķi uzticēšanās lēmumi, atsevišķas sertifikātu ķēdes un atsevišķi kļūdu ziņojumi. Starpniekserveris ar organizācijas CA un publiska vietne ar publisku ķēdi var likumīgi prasīt atšķirīgu pārbaudes konfigurāciju, un tā nav nepareiza konfigurācija.

Uztveriet tās kā divus savienojumus, kas nejauši dala vienu ligzdu, jo tādi tie ir.

Ko CONNECT patiesībā tunelē

Klients nosūta CONNECT pieprasījumu, nosaucot resursdatoru un portu, un starpniekserveris atver TCP savienojumu uz šo mērķi. Pēc tam, kad starpniekserveris atbild, nākamie baiti tiek pārraidīti bez interpretācijas, tāpēc vietnes TLS rokas sasveicināšanās iziet caur starpniekserveri neskarta. Tā starpniekserveris uzzina galamērķa nosaukumu un savienojuma metadatus, bet no šī izkārtojuma nesaņem atšifrētas lapas.

Šī atšķirība ir viss tuneļa režīma drošības arguments, un tā ir arī tā robeža.

HTTP starpniekserveris bez TLS starpniekservera lēcienā joprojām pārvieto HTTPS vietni caur CONNECT. Klienta un starpniekservera apmaiņa notiek atklāti, bet vietnes savienojums tā nav, un visa tā saukšana par HTTPS starpniekserveri slēpj šo atšķirību.

Kurš sertifikāts neizdevās

Kad pārbaude neizdodas, izlasiet kļūdā nosaukto galu pirms jebkura uzticēšanās iestatījuma maiņas. Abas kļūdas terminālī izskatās līdzīgi un norāda uz pilnīgi atšķirīgiem labojumiem, tāpēc pirmais jautājums vienmēr ir, kurš savienojums atteicās.

curl atdala opcijas tieši šī iemesla dēļ. Starpniekservera CA fails konfigurē starpniekservera pārbaudi, bet CA fails konfigurē servera pārbaudi, un piemērojamās uzticēšanās krātuves uzvedība arī ir atkarīga no tā, kā curl tika būvēts.

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

Pārbaudes nomākšana nav labojums. Tā neko nepierāda par nevienu no abiem galiem.

Inspekcija ir cits izkārtojums

TLS inspekcija nav tunelēšana. Inspicējošs starpnieks izbeidz uzticēšanās attiecības ar vietni un uzrāda klientam savu sertifikātu, tāpēc klients pārbauda starpnieku, nevis vietni. Tas var būt likumīgi apstiprināta dizaina ietvaros, un tas ir būtiski cits apgalvojums nekā pārraide baitu pa baitam. Nepieņemiet, ka katrs starpniekserveris inspicē, un nepieņemiet, ka šifrēts starpniekservera lēciens to izslēdz.

Organizācijas CA jūsu uzticēšanās krātuvē ir mājiens par to, kādā izkārtojumā jūs esat, nevis pierādījums. Jautājiet par dizainu, nevis seciniet to no sertifikātu ķēdes.

Šie divi izkārtojumi sniedz atšķirīgas atbildes uz jautājumu, kas var lasīt lapu.

Salīdziniet starpniekserveri un VPN tajās pašās četrās rindās

Salīdzinājums kļūst noderīgs tikai tad, kad abi izvietojumi ir aprakstīti vienādi.

Starpniekserveris, kas konfigurēts vienam pieprasījumam, aptver šo pieprasījumu. Tas nepalaiž caur sevi katru ierīces procesu, un piemēra komanda ir tieši tik šaura. VPN pārklājums ir atkarīgs no tā maršrutēšanas un lietojumprogrammu politikas, kas arī jāpārbauda, nevis jāpieņem. Neviens no variantiem neaptver visu tikai tāpēc, ka tas tika instalēts.

Uzrakstiet četras rindas katram variantam, un strīds parasti atrisinās pats. Noderīgais salīdzinājums nav tas, kura etiķete izklausās šifrētāka. Bet gan tas, kuri segmenti ir aizsargāti, kas tiek pārbaudīts to galos, kuriem starpniekiem jūs uzticaties un kādu satiksmi politika patiešām aptver.