Ein HTTPS-proxy tyder to TLS-tilkoplingar, ikkje éi

Etiketten HTTPS-proxy skildrar berre transporten mellom klienten din og proxyen, og ingenting meir. Han seier ikkje at nettstaden bak er kryptert av den same tilkoplinga, og han seier ikkje at proxyen kan lese sida. Når du skil dei to tilkoplingane, sluttar sertifikatfeil å vere mystiske, og samanlikninga med ein VPN blir konkret.

To endepunktspar, to verifiseringar

I vanleg tunnellmodus finst det to TLS-tilhøve. Det første går frå klienten din til proxyen og autentiserer proxyen. Det andre går frå klienten din til nettstaden inne i tunnelen og autentiserer nettstaden. Dei feilar uavhengig og blir konfigurerte uavhengig.

Dei har separate tillitsavgjerder, separate sertifikatkjeder og separate feilmeldingar. Ein proxy med ein organisatorisk CA og ein offentleg nettstad med ei offentleg kjede kan legitimt trenge ein annan verifiseringskonfigurasjon, og det er ikkje ein feilkonfigurasjon.

Behandle dei som to tilkoplingar som tilfeldigvis deler ein socket, for det er det dei er.

Kva CONNECT faktisk tunnelerer

Klienten sender ein CONNECT-førespurnad som nemner vert og port, og proxyen opnar ei TCP-tilkopling til det målet. Etter at proxyen svarar, blir byta som følgjer vidaresende utan tolking, og difor går TLS-handtrykket til nettstaden gjennom proxyen urørt. Proxyen lærer dermed destinasjonsnamnet og metadataa til tilkoplinga, og han mottek ikkje dekrypterte sider frå den ordninga.

Den skilnaden er heile tryggingsargumentet for tunnellmodus, og han er også grensa.

Ein HTTP-proxy utan TLS på proxyhoppet ber framleis ein HTTPS-nettstad gjennom CONNECT. Utvekslinga mellom klient og proxy er i klartekst, medan tilkoplinga til nettstaden ikkje er det, og å kalle alt saman ein HTTPS-proxy gøymer den skilnaden.

Kva sertifikat som feila

Når verifiseringa feilar, les endepunktet som er nemnt i feilen, før du endrar noka tillitsinnstilling. Dei to feila ser like ut i ein terminal og peikar på heilt ulike rettingar, difor er det første spørsmålet alltid kva tilkopling som avviste.

curl skil alternativa nettopp av denne grunnen. CA-fila til proxyen konfigurerer verifiseringa av proxyen, medan CA-fila konfigurerer verifiseringa av serveren, og åtferda til det gjeldande tillitslageret avheng òg av korleis curl vart bygd.

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

Å undertrykke ein sjekk er ikkje ein reparasjon. Det beviser ingenting om nokon av endepunkta.

Inspeksjon er ei anna ordning

TLS-inspeksjon er ikkje tunnelering. Ein inspiserande mellommann avsluttar tillitshøvet mot nettstaden og presenterer sitt eige sertifikat for klienten, så klienten verifiserer mellommannen i staden for nettstaden. Det kan vere legitimt under eit godkjent design, og det er ein vesentleg annan påstand enn vidaresending byte for byte. Ikkje anta at kvar proxy inspiserer, og ikkje anta at eit kryptert proxyhopp utelukkar det.

Ein organisatorisk CA i tillitslageret ditt er eit hint om kva ordning du er i, ikkje eit bevis. Spør om designet i staden for å utleie det frå ei sertifikatkjede.

Desse to ordningane gir ulike svar på spørsmålet om kven som kan lese sida.

Samanlikn proxy og VPN på dei same fire linjene

Samanlikninga blir først nyttig når begge utrullingane blir skildra på same måte.

Ein proxy som er konfigurert for éin førespurnad, dekkjer den førespurnaden. Han sender ikkje kvar prosess på eininga gjennom seg, og eksempelkommandoen er nøyaktig så smal. Dekninga til ein VPN avheng av ruttinga og programpolicyen, som òg må undersøkjast i staden for å antakast. Ingen av alternativa dekkjer alt berre fordi det vart installert.

Skriv dei fire linjene for kvart alternativ, og argumentet løyser seg vanlegvis sjølv. Den nyttige samanlikninga er ikkje kva etikett som høyrest meir kryptert ut. Det er kva segment som er verna, kven som blir verifisert ved endane, kva mellomledd du stolar på, og kva trafikk policyen faktisk omfattar.