Een HTTPS-proxy betekent twee TLS-verbindingen, niet één
De proxyhop en de website zijn afzonderlijke TLS-relaties met afzonderlijk vertrouwen. Lees welk eindpunt faalde voordat u een certificaatinstelling wijzigt.
Het label HTTPS-proxy beschrijft alleen het transport tussen uw client en de proxy, en niets meer. Het zegt niet dat de website erachter door dezelfde verbinding is versleuteld, en het zegt niet dat de proxy de pagina kan lezen. Zodra u de twee verbindingen scheidt, houden certificaatfouten op mysterieus te zijn en wordt de vergelijking met een VPN concreet.
Twee eindpuntparen, twee verificaties
In de gewone tunnelmodus zijn er twee TLS-relaties. De eerste loopt van uw client naar de proxy en authenticeert de proxy. De tweede loopt van uw client naar de website binnen de tunnel en authenticeert de website. Ze falen onafhankelijk en worden onafhankelijk geconfigureerd.
Ze hebben afzonderlijke vertrouwensbeslissingen, afzonderlijke certificaatketens en afzonderlijke foutmeldingen. Een proxy met een organisatie-CA en een openbare website met een openbare keten kunnen legitiem een andere verificatieconfiguratie nodig hebben, en dat is geen verkeerde configuratie.
Behandel ze als twee verbindingen die toevallig één socket delen, want dat is wat ze zijn.
Wat CONNECT feitelijk tunnelt
De client stuurt een CONNECT-verzoek met de host en poort, en de proxy opent een TCP-verbinding naar dat doel. Nadat de proxy antwoordt, worden de volgende bytes doorgegeven zonder interpretatie, daarom gaat de TLS-handshake van de website onaangeroerd door de proxy. De proxy leert zo de bestemmingsnaam en de metadata van de verbinding, en hij ontvangt geen ontsleutelde pagina's uit die opzet.
Dat onderscheid is het hele beveiligingsargument voor de tunnelmodus, en het is ook de grens ervan.
Een HTTP-proxy zonder TLS op de proxyhop draagt nog steeds een HTTPS-website via CONNECT. De uitwisseling tussen client en proxy is in klare tekst terwijl de websiteverbinding dat niet is, en het geheel een HTTPS-proxy noemen verbergt dat verschil.
Welk certificaat faalde
Wanneer verificatie faalt, lees dan het eindpunt dat in de fout wordt genoemd voordat u een vertrouwensinstelling wijzigt. De twee fouten lijken in een terminal op elkaar en wijzen op volledig verschillende oplossingen, daarom is de eerste vraag altijd welke verbinding weigerde.
curl scheidt de opties precies om deze reden. Het CA-bestand van de proxy configureert de verificatie van de proxy, terwijl het CA-bestand de verificatie van de server configureert, en het gedrag van de toepasselijke vertrouwensopslag hangt ook af van hoe curl is gebouwd.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/Een controle onderdrukken is geen reparatie. Het bewijst niets over een van beide eindpunten.
Inspectie is een andere opzet
TLS-inspectie is geen tunneling. Een inspecterende tussenpartij beëindigt de vertrouwensrelatie naar de website en presenteert zijn eigen certificaat aan de client, zodat de client de tussenpartij verifieert in plaats van de site. Dat kan legitiem zijn onder een goedgekeurd ontwerp, en het is een wezenlijk andere bewering dan byte voor byte doorgeven. Ga er niet van uit dat elke proxy inspecteert, en ga er niet van uit dat een versleutelde proxyhop dat uitsluit.
Een organisatie-CA in uw vertrouwensopslag is een aanwijzing voor de opzet waarin u zich bevindt, geen bewijs. Vraag naar het ontwerp in plaats van het af te leiden uit een certificaatketen.
Die twee opzetten geven verschillende antwoorden op de vraag wie de pagina kan lezen.
Vergelijk proxy en VPN op dezelfde vier regels
De vergelijking wordt pas nuttig wanneer beide implementaties op dezelfde manier worden beschreven.
| 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 |
Een proxy die voor één verzoek is geconfigureerd, dekt dat verzoek. Hij stuurt niet elk proces op het apparaat erdoorheen, en het voorbeeldcommando is precies zo smal. De dekking van een VPN hangt af van de routering en het applicatiebeleid, die ook moeten worden onderzocht in plaats van aangenomen. Geen van beide opties dekt alles alleen omdat ze is geïnstalleerd.
Schrijf de vier regels voor elke optie en het argument lost zich meestal vanzelf op. De nuttige vergelijking is niet welk label versleutelder klinkt. Het is welke segmenten zijn beschermd, wie aan hun uiteinden wordt geverifieerd, welke tussenpartijen u vertrouwt, en welk verkeer het beleid werkelijk omvat.