En HTTPS-proxy betyr to TLS-tilkoblinger, ikke én

Etiketten HTTPS-proxy beskriver bare transporten mellom klienten din og proxyen, og ingenting mer. Den sier ikke at nettstedet bak er kryptert av den samme tilkoblingen, og den sier ikke at proxyen kan lese siden. Når du skiller de to tilkoblingene, slutter sertifikatfeil å være mystiske, og sammenligningen med en VPN blir konkret.

To endepunktspar, to verifiseringer

I vanlig tunnellmodus finnes det to TLS-forhold. Det første går fra klienten din til proxyen og autentiserer proxyen. Det andre går fra klienten din til nettstedet inne i tunnelen og autentiserer nettstedet. De feiler uavhengig og konfigureres uavhengig.

De har separate tillitsbeslutninger, separate sertifikatkjeder og separate feilmeldinger. En proxy med en organisatorisk CA og et offentlig nettsted med en offentlig kjede kan legitimt trenge en annen verifiseringskonfigurasjon, og det er ikke en feilkonfigurasjon.

Behandle dem som to tilkoblinger som tilfeldigvis deler en socket, for det er det de er.

Hva CONNECT faktisk tunnelerer

Klienten sender en CONNECT-forespørsel som navngir vert og port, og proxyen åpner en TCP-tilkobling til det målet. Etter at proxyen svarer, videresendes bytene som følger uten tolkning, og derfor går nettstedets TLS-håndtrykk gjennom proxyen urørt. Proxyen lærer dermed destinasjonsnavnet og tilkoblingens metadata, og den mottar ikke dekrypterte sider fra den ordningen.

Den forskjellen er hele sikkerhetsargumentet for tunnellmodus, og den er også grensen.

En HTTP-proxy uten TLS på proxyhoppet bærer fortsatt et HTTPS-nettsted gjennom CONNECT. Utvekslingen mellom klient og proxy er i klartekst, mens nettstedets tilkobling ikke er det, og å kalle alt sammen en HTTPS-proxy skjuler den forskjellen.

Hvilket sertifikat feilet

Når verifiseringen feiler, les endepunktet som er navngitt i feilen, før du endrer noen tillitsinnstilling. De to feilene ser like ut i en terminal og peker på helt forskjellige rettelser, derfor er det første spørsmålet alltid hvilken tilkobling som avviste.

curl skiller alternativene nettopp av denne grunnen. Proxyens CA-fil konfigurerer verifiseringen av proxyen, mens CA-filen konfigurerer verifiseringen av serveren, og oppførselen til det gjeldende tillitslageret avhenger også av hvordan curl ble bygget.

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

Å undertrykke en sjekk er ikke en reparasjon. Det beviser ingenting om noen av endepunktene.

Inspeksjon er en annen ordning

TLS-inspeksjon er ikke tunellering. En inspiserende mellommann avslutter tillitsforholdet mot nettstedet og presenterer sitt eget sertifikat for klienten, så klienten verifiserer mellommannen i stedet for nettstedet. Det kan være legitimt under et godkjent design, og det er en vesentlig annen påstand enn videresending byte for byte. Ikke anta at enhver proxy inspiserer, og ikke anta at et kryptert proxyhopp utelukker det.

En organisatorisk CA i tillitslageret ditt er et hint om hvilken ordning du er i, ikke et bevis. Spør om designet i stedet for å utlede det fra en sertifikatkjede.

Disse to ordningene gir forskjellige svar på spørsmålet om hvem som kan lese siden.

Sammenlign proxy og VPN på de samme fire linjene

Sammenligningen blir først nyttig når begge utrullingen beskrives på samme måte.

En proxy som er konfigurert for én forespørsel, dekker den forespørselen. Den sender ikke hver prosess på enheten gjennom seg, og eksempelkommandoen er nøyaktig så smal. Dekningen til en VPN avhenger av rutingen og applikasjonspolicyen, som også må undersøkes i stedet for å antas. Ingen av alternativene dekker alt bare fordi det ble installert.

Skriv de fire linjene for hvert alternativ, og argumentet løser seg vanligvis selv. Den nyttige sammenligningen er ikke hvilken etikett som høres mer kryptert ut. Det er hvilke segmenter som er beskyttet, hvem som verifiseres ved endene, hvilke mellomledd du stoler på, og hvilken trafikk policyen faktisk omfatter.