’n HTTPS-proxy beteken twee TLS-verbindings, nie een nie
Die proxy-hop en die webwerf is aparte TLS-verhoudings met aparte vertroue. Lees watter eindpunt gefaal het voordat jy enige sertifikaatinstelling verander.
Die etiket HTTPS-proxy beskryf die vervoer tussen jou kliënt en die proxy, en niks meer nie. Dit sê nie dat die webwerf daaragter deur dieselfde verbinding geënkripteer word nie, en dit sê nie dat die proxy die bladsy kan lees nie. Sodra jy die twee verbindings skei, hou sertifikaatfoute op om raaiselagtig te wees en word die vergelyking met ’n VPN konkreet.
Twee eindpuntpare, twee verifikasies
In gewone tonnelmodus is daar twee TLS-verhoudings. Die eerste loop van jou kliënt na die proxy en verifieer die proxy. Die tweede loop van jou kliënt na die webwerf binne die tonnel, en verifieer die webwerf. Hulle faal onafhanklik en hulle word onafhanklik opgestel.
Hulle het aparte vertrouebesluite, aparte sertifikaatkettings en aparte foutboodskappe. ’n Proxy met ’n organisasie-CA en ’n openbare webwerf met ’n openbare ketting kan wettiglik verskillende verifikasiekonfigurasie nodig hê, en dit is nie ’n foutkonfigurasie nie.
Behandel hulle as twee verbindings wat toevallig ’n sokket deel, want dit is wat hulle is.
Wat CONNECT werklik tonnel
Die kliënt stuur ’n CONNECT-versoek wat die gasheer en poort noem, en die proxy open ’n TCP-verbinding na daardie teiken. Nadat die proxy antwoord, word die grepe wat volg sonder interpretasie deurgestuur, en daarom reis die webwerf se TLS-handdruk onaangeraak deur die proxy. Die proxy leer dus die bestemmingsnaam en die verbindingsmetadata, en hy ontvang nie ontslote bladsye uit daardie reëling nie.
Daardie onderskeid is die hele veiligheidsargument vir tonnelmodus, en dit is ook sy beperking.
’n HTTP-proxy sonder TLS op die proxy-hop dra steeds ’n HTTPS-webwerf deur CONNECT. Die kliënt-tot-proxy-uitruiling is in die ope lug terwyl die webwerfverbinding dit nie is nie, en om die hele ding ’n HTTPS-proxy te noem, verberg daardie verskil.
Watter sertifikaat het gefaal
Wanneer verifikasie faal, lees die eindpunt wat in die fout genoem word voordat jy enige vertroue-instelling verander. Die twee foute lyk in ’n terminal dieselfde en wys op heeltemal verskillende regstellings, en daarom is die eerste vraag altyd watter verbinding geweier het.
curl skei die opsies juis om hierdie rede. Die proxy-CA-lêer stel die verifikasie van die proxy op, terwyl die CA-lêer die verifikasie van die bediener opstel, en die toepaslike gedrag van die vertrouestoor hang ook daarvan af hoe curl gebou is.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/Om ’n kontrole te onderdruk is nie ’n herstelling nie. Dit bewys niks oor enige van die twee eindpunte nie.
Inspeksie is ’n ander reëling
TLS-inspeksie is nie tonneling nie. ’n Inspekteerder-tussenparty beëindig die webwerfgerigte vertroueverhouding en bied sy eie sertifikaat aan die kliënt, so die kliënt verifieer die tussenparty eerder as die werf. Dit kan wettig wees onder ’n goedgekeurde ontwerp, en dit is ’n wesenlik ander bewering as byte-vir-byte-deurgee. Moenie aanvaar dat elke proxy inspekteer nie, en moenie aanvaar dat ’n geënkripteerde proxy-hop dit uitsluit nie.
’n Organisasie-CA in jou vertrouestoor is ’n wenk oor watter reëling jy in is, nie ’n bewys nie. Vra na die ontwerp eerder as om dit uit ’n sertifikaatketting af te lei.
Daardie twee reëlings gee verskillende antwoorde op die vraag wie die bladsy kan lees.
Vergelyk proxy en VPN op dieselfde vier reëls
Die vergelyking word eers bruikbaar wanneer albei ontplooiings op dieselfde manier beskryf word.
| Line | What to state |
|---|---|
| Protected segments | Which hops are encrypted, and between which endpoints |
| Verified identities | What each end proves, and against which trust anchor |
| Trusted intermediaries | Who can read or alter traffic by design |
| Traffic included | Which processes and destinations the policy actually covers |
’n Proxy wat vir een versoek opgestel is, dek daardie versoek. Dit stuur nie elke proses op die toestel daardeur nie, en die voorbeeldopdrag is presies so smal. ’n VPN se dekking hang af van sy roetering en toepassingsbeleid, wat ook ondersoek moet word eerder as aanvaar. Nie een van die twee opsies dek alles bloot omdat dit geïnstalleer is nie.
Skryf die vier reëls vir elke opsie en die argument los homself gewoonlik op. Die nuttige vergelyking is nie watter etiket meer geënkripteer klink nie. Dit is watter segmente beskerm word, wie aan hulle ente geverifieer word, watter tussenpartye jy vertrou, en watter verkeer die beleid werklik insluit.