Un proxy HTTPS înseamnă două conexiuni TLS, nu una
Saltul prin proxy și site-ul sunt relații TLS separate, cu încredere separată. Citiți care capăt a eșuat înainte de a schimba orice setare de certificat.
Eticheta proxy HTTPS descrie doar transportul dintre clientul dvs. și proxy, și nimic mai mult. Nu spune că site-ul din spate este criptat de aceeași conexiune și nu spune că proxy-ul poate citi pagina. Odată ce separați cele două conexiuni, erorile de certificat încetează să fie misterioase, iar comparația cu un VPN devine concretă.
Două perechi de capete, două verificări
În modul tunel obișnuit există două relații TLS. Prima merge de la clientul dvs. la proxy și autentifică proxy-ul. A doua merge de la clientul dvs. la site-ul din interiorul tunelului și autentifică site-ul. Ele eșuează independent și sunt configurate independent.
Au decizii de încredere separate, lanțuri de certificate separate și mesaje de eroare separate. Un proxy cu o CA organizațională și un site public cu un lanț public pot avea în mod legitim nevoie de o configurație de verificare diferită, iar aceasta nu este o configurare greșită.
Tratați-le ca două conexiuni care împart întâmplător același socket, pentru că exact asta sunt.
Ce tunelează de fapt CONNECT
Clientul trimite o cerere CONNECT cu numele gazdei și portul, iar proxy-ul deschide o conexiune TCP către acea țintă. După ce proxy-ul răspunde, octeții care urmează sunt retransmiși fără interpretare, de aceea handshake-ul TLS al site-ului trece prin proxy neatins. Astfel proxy-ul află numele destinației și metadatele conexiunii și nu primește pagini decriptate din acest aranjament.
Această distincție este întregul argument de securitate al modului tunel și este totodată limita lui.
Un proxy HTTP fără TLS pe saltul proxy transportă totuși un site HTTPS prin CONNECT. Schimbul dintre client și proxy este în clar, în timp ce conexiunea site-ului nu este, iar numirea întregului lucru proxy HTTPS ascunde această diferență.
Care certificat a eșuat
Când verificarea eșuează, citiți capătul numit în eroare înainte de a schimba orice setare de încredere. Cele două erori arată similar într-un terminal și indică remedieri complet diferite, de aceea prima întrebare este mereu care conexiune a refuzat.
curl separă opțiunile exact din acest motiv. Fișierul CA al proxy-ului configurează verificarea proxy-ului, în timp ce fișierul CA configurează verificarea serverului, iar comportamentul depozitului de încredere aplicabil depinde și de modul în care a fost construit curl.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/Suprimarea unei verificări nu este o reparație. Nu demonstrează nimic despre niciunul dintre cele două capete.
Inspecția este un alt aranjament
Inspecția TLS nu este tunelare. Un intermediar care inspectează încheie relația de încredere față de site și prezintă clientului propriul certificat, așa că clientul verifică intermediarul, nu site-ul. Acest lucru poate fi legitim într-un proiect aprobat și este o afirmație fundamental diferită de retransmiterea octet cu octet. Nu presupuneți că fiecare proxy inspectează și nu presupuneți că un salt proxy criptat exclude acest lucru.
O CA organizațională în depozitul dvs. de încredere este un indiciu despre aranjamentul în care vă aflați, nu o dovadă. Cereți proiectul în loc să îl deduceți dintr-un lanț de certificate.
Aceste două aranjamente dau răspunsuri diferite la întrebarea cine poate citi pagina.
Comparați proxy și VPN pe aceleași patru linii
Comparația devine utilă doar când ambele implementări sunt descrise în același fel.
| 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 |
Un proxy configurat pentru o singură cerere acoperă acea cerere. Nu trimite fiecare proces al dispozitivului prin el, iar comanda exemplu este exact atât de îngustă. Acoperirea unui VPN depinde de rutare și de politica aplicațiilor, care trebuie și ele inspectate, nu presupuse. Niciuna dintre opțiuni nu acoperă totul doar pentru că a fost instalată.
Scrieți cele patru linii pentru fiecare opțiune și argumentul se rezolvă de obicei singur. Comparația utilă nu este care etichetă sună mai criptată. Ci care segmente sunt protejate, cine este verificat la capetele lor, în ce intermediari aveți încredere și ce trafic include politica de fapt.