En HTTPS-proxy innebär två TLS-anslutningar, inte en
Proxyhoppet och webbplatsen är separata TLS-relationer med separat förtroende. Läs vilken ändpunkt som misslyckades innan du ändrar någon certifikatinställning.
Beteckningen HTTPS-proxy beskriver transporten mellan din klient och proxyn, och inget mer. Den säger inte att webbplatsen bakom krypteras av samma anslutning, och den säger inte att proxyn kan läsa sidan. När du skiljer de två anslutningarna åt slutar certifikatfel vara mystiska och jämförelsen med en VPN blir konkret.
Två par av ändpunkter, två verifieringar
I vanligt tunnelläge finns två TLS-relationer. Den första går från din klient till proxyn och autentiserar proxyn. Den andra går från din klient till webbplatsen inne i tunneln och autentiserar webbplatsen. De misslyckas oberoende av varandra och de konfigureras oberoende av varandra.
De har separata förtroendebeslut, separata certifikatkedjor och separata felmeddelanden. En proxy som använder en organisations-CA och en offentlig webbplats som använder en offentlig kedja kan legitimt behöva olika verifieringskonfiguration, och det är inte en felkonfiguration.
Behandla dem som två anslutningar som råkar dela en socket, för det är vad de är.
Vad CONNECT faktiskt tunnlar
Klienten skickar en CONNECT-begäran som anger värd och port, och proxyn öppnar en TCP-anslutning till målet. När proxyn har svarat vidarebefordras byten som följer utan tolkning, vilket är anledningen till att webbplatsens TLS-handskakning färdas genom proxyn orörd. Proxyn får därför reda på destinationsnamnet och anslutningsmetadata, och den tar inte emot dekrypterade sidor genom detta arrangemang.
Den skillnaden är hela säkerhetsargumentet för tunnelläge, och den är också dess gräns.
En HTTP-proxy utan TLS på proxyhoppet bär fortfarande en HTTPS-webbplats genom CONNECT. Utbytet mellan klient och proxy är i klartext medan webbplatsanslutningen inte är det, och att kalla hela saken för HTTPS-proxy döljer den skillnaden.
Vilket certifikat som misslyckades
När verifieringen misslyckas, läs den ändpunkt som anges i felet innan du ändrar någon förtroendeinställning. De två felen ser likadana ut i en terminal och pekar på helt olika åtgärder, vilket är anledningen till att den första frågan alltid är vilken anslutning som nekades.
curl skiljer på alternativen just av denna anledning. Proxy-CA-filen konfigurerar verifieringen av proxyn, medan CA-filen konfigurerar verifieringen av servern, och vilket beteende för förtroendelagret som gäller beror också på hur curl byggdes.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/Att undertrycka en kontroll är ingen reparation. Det bevisar ingenting om någon av ändpunkterna.
Inspektion är ett annat arrangemang
TLS-inspektion är inte tunnling. En inspekterande mellanhand avslutar den webbplatsvända förtroenderelationen och presenterar sitt eget certifikat för klienten, så klienten verifierar mellanhanden i stället för webbplatsen. Det kan vara legitimt enligt en godkänd design, och det är ett väsensskilt påstående från vidarebefordran byte för byte. Anta inte att varje proxy inspekterar, och anta inte att ett krypterat proxyhopp utesluter det.
En organisations-CA i ditt förtroendelager är en antydan om vilket arrangemang du befinner dig i, inte ett bevis. Fråga efter designen i stället för att sluta dig till den från en certifikatkedja.
De två arrangemangen ger olika svar på frågan vem som kan läsa sidan.
Jämför proxy och VPN på samma fyra rader
Jämförelsen blir bara användbar när båda driftsättningarna beskrivs på samma sätt.
| 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 |
En proxy som konfigurerats för en begäran täcker den begäran. Den skickar inte varje process på enheten genom sig, och exempelkommandot är precis så smalt. En VPN:s täckning beror på dess routing- och applikationspolicy, som också måste inspekteras i stället för antas. Inget av alternativen täcker allt bara för att det installerades.
Skriv de fyra raderna för varje alternativ och argumentet löser sig vanligtvis självt. Den användbara jämförelsen är inte vilken etikett som låter mer krypterad. Det är vilka segment som skyddas, vem som verifieras vid deras ändar, vilka mellanhänder du litar på och vilken trafik policyn faktiskt omfattar.