HTTPS proxy znači dvije TLS veze, a ne jednu

Oznaka HTTPS proxy opisuje samo prijenos između vašeg klijenta i proxyja, i ništa više. Ona ne kaže da je web stranica iza njega šifrirana tom istom vezom, niti da proxy može čitati stranicu. Kad razdvojite dvije veze, greške certifikata prestaju biti tajanstvene i poređenje s VPN-om postaje konkretno.

Dva para krajnjih tačaka, dvije provjere

U običnom tunelskom režimu postoje dva TLS odnosa. Prvi ide od vašeg klijenta do proxyja i autentificira proxy. Drugi ide od vašeg klijenta do web stranice unutar tunela i autentificira web stranicu. Oni padaju neovisno i konfiguriraju se neovisno.

Imaju odvojene odluke o povjerenju, odvojene lance certifikata i odvojene poruke o grešci. Proxy koji koristi organizacijski CA i javna web stranica s javnim lancem mogu legitimno trebati različitu konfiguraciju provjere, i to nije pogrešna konfiguracija.

Tretirajte ih kao dvije veze koje slučajno dijele isti socket, jer to one i jesu.

Šta CONNECT zapravo tunelira

Klijent šalje CONNECT zahtjev s imenom hosta i porta, a proxy otvara TCP vezu prema tom cilju. Nakon što proxy odgovori, bajtovi koji slijede prenose se bez interpretacije, zato TLS rukovanje web stranice prolazi kroz proxy netaknuto. Proxy tako saznaje ime odredišta i metapodatke veze, ali iz tog aranžmana ne prima dešifrirane stranice.

Ta razlika je cijeli sigurnosni argument za tunelski režim, i ujedno njegova granica.

HTTP proxy bez TLS-a na proxy skoku i dalje prenosi HTTPS stranicu kroz CONNECT. Razmjena klijent-proxy je otvorena, dok veza sa stranicom nije, i nazivanje svega toga HTTPS proxyjem skriva tu razliku.

Koji certifikat je zakazao

Kad provjera ne uspije, pročitajte krajnju tačku navedenu u grešci prije nego promijenite bilo koju postavku povjerenja. Dvije greške izgledaju slično u terminalu i upućuju na potpuno različite popravke, zato je prvo pitanje uvijek koja je veza odbijena.

curl razdvaja opcije upravo iz tog razloga. Proxy CA datoteka konfigurira provjeru proxyja, dok CA datoteka konfigurira provjeru servera, a ponašanje primjenjivog spremišta povjerenja također ovisi o tome kako je curl izgrađen.

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

Potiskivanje provjere nije popravak. Ono ne dokazuje ništa ni o jednoj krajnjoj tački.

Inspekcija je drugačiji aranžman

TLS inspekcija nije tuneliranje. Inspekcijski posrednik prekida odnos povjerenja prema web stranici i klijentu predstavlja vlastiti certifikat, pa klijent provjerava posrednika umjesto stranice. To može biti legitimno u odobrenom dizajnu, ali je bitno drugačija tvrdnja od prijenosa bajt po bajt. Ne pretpostavljajte da svaki proxy vrši inspekciju, i ne pretpostavljajte da šifrirani proxy skok to isključuje.

Organizacijski CA u vašem spremištu povjerenja nagovještaj je u kojem se aranžmanu nalazite, a ne dokaz. Pitajte za dizajn umjesto da ga zaključujete iz lanca certifikata.

Ta dva aranžmana daju različite odgovore na pitanje ko može čitati stranicu.

Uporedite proxy i VPN na ista četiri reda

Poređenje postaje korisno tek kad su oba postavljanja opisana na isti način.

Proxy konfiguriran za jedan zahtjev pokriva taj zahtjev. On ne propušta svaki proces na uređaju kroz sebe, i primjer naredbe je upravo toliko uzak. Pokrivenost VPN-a ovisi o njegovom rutiranju i politici aplikacija, što se također mora provjeriti, a ne pretpostaviti. Nijedna opcija ne pokriva sve samo zato što je instalirana.

Napišite četiri reda za svaku opciju i rasprava se obično sama riješi. Korisno poređenje nije koja oznaka zvuči šifriranije. Nego koji su segmenti zaštićeni, ko je verificiran na njihovim krajevima, kojim posrednicima vjerujete i koji promet politika zaista pokriva.