En HTTPS-proxy betyder to TLS-forbindelser, ikke én

Etiketten HTTPS-proxy beskriver kun transporten mellem din klient og proxyen, og intet mere. Den siger ikke, at webstedet bagved er krypteret af den samme forbindelse, og den siger ikke, at proxyen kan læse siden. Når du adskiller de to forbindelser, holder certifikatfejl op med at være mystiske, og sammenligningen med en VPN bliver konkret.

To endepunktpar, to verifikationer

I almindelig tunneltilstand er der to TLS-forhold. Det første går fra din klient til proxyen og autentificerer proxyen. Det andet går fra din klient til webstedet inde i tunnelen og autentificerer webstedet. De fejler uafhængigt, og de konfigureres uafhængigt.

De har separate tillidsbeslutninger, separate certifikatkæder og separate fejlmeddelelser. En proxy med en organisatorisk CA og et offentligt websted med en offentlig kæde kan legitimt have brug for forskellig verifikationskonfiguration, og det er ikke en fejlkonfiguration.

Behandl dem som to forbindelser, der tilfældigvis deler en socket, for det er hvad de er.

Hvad CONNECT egentlig tunnelerer

Klienten sender en CONNECT-anmodning med vært og port, og proxyen åbner en TCP-forbindelse til det mål. Når proxyen har svaret, videresendes de følgende bytes uden fortolkning, og derfor passerer webstedets TLS-håndtryk gennem proxyen uberørt. Proxyen lærer dermed destinationsnavnet og forbindelsens metadata, og den modtager ikke dekrypterede sider fra den ordning.

Denne forskel er hele sikkerhedsargumentet for tunneltilstand, og det er også dens grænse.

En HTTP-proxy uden TLS på proxyhoppet bærer stadig et HTTPS-websted gennem CONNECT. Udvekslingen mellem klient og proxy er i klartekst, mens webstedets forbindelse ikke er, og at kalde det hele en HTTPS-proxy skjuler den forskel.

Hvilket certifikat fejlede

Når verifikationen fejler, skal du læse det endepunkt, der nævnes i fejlen, før du ændrer nogen tillidsindstilling. De to fejl ser ens ud i en terminal og peger på helt forskellige rettelser, og derfor er det første spørgsmål altid, hvilken forbindelse der blev afvist.

curl adskiller valgmulighederne netop af denne grund. Proxyens CA-fil konfigurerer verifikationen af proxyen, mens CA-filen konfigurerer verifikationen af serveren, og den relevante tillidslagers adfærd afhænger også af, hvordan curl blev bygget.

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

At undertrykke et tjek er ikke en reparation. Det beviser intet om noget af endepunkterne.

Inspektion er en anden ordning

TLS-inspektion er ikke tunellering. En inspicerende mellemmand afslutter tillidsforholdet mod webstedet og præsenterer sin egen certifikat for klienten, så klienten verificerer mellemmanden i stedet for webstedet. Det kan være legitimt under et godkendt design, og det er en væsentligt anderledes påstand end videresendelse byte for byte. Antag ikke, at enhver proxy inspicerer, og antag ikke, at et krypteret proxyhop udelukker det.

En organisatorisk CA i din tillidslager er et fingerpeg om, hvilken ordning du er i, ikke et bevis. Spørg efter designet i stedet for at udlede det af en certifikatkæde.

Disse to ordninger giver forskellige svar på spørgsmålet om, hvem der kan læse siden.

Sammenlign proxy og VPN på de samme fire linjer

Sammenligningen bliver først nyttig, når begge udrulninger beskrives på samme måde.

En proxy, der er konfigureret til én anmodning, dækker den anmodning. Den sender ikke hver proces på enheden igennem sig, og eksempelkommandoen er præcis så snæver. En VPN's dækning afhænger af dens routing og applikationspolitik, som også skal undersøges i stedet for antages. Ingen af mulighederne dækker alt, bare fordi den blev installeret.

Skriv de fire linjer for hver mulighed, og argumentet løser sig normalt selv. Den nyttige sammenligning er ikke, hvilket label der lyder mere krypteret. Det er, hvilke segmenter der er beskyttet, hvem der verificeres ved deres ender, hvilke mellemmænd du stoler på, og hvilken trafik politikken faktisk omfatter.