Amit a helyi hálózat még mindig lát a VPN-en keresztül

Három megfigyelő olvad össze egyetlen kérdéssé, amikor valaki azt kérdezi, elrejti-e a VPN a forgalmát: a hálózat, amelyhez csatlakozik, a gép a kezében és az alagút üzemeltetője. Mindegyik másvalamit tanul meg, és az alagút mindegyik nézetet másképp változtatja meg. Érdemes a másik irányból dolgozni, és abból az állításból kiindulni, amely megfogalmazódik, mert az állításnak kell kiállnia a vizsgálatot. Döntsd el, melyik állításra van szükséged, aztán hasonlítsd össze vele az eszközöket.

Első állítás: senki sem tudja elolvasni a forgalmat

Kezdd a legszűkebb állítással: a hasznos teher olvashatatlan marad. Az útvonalon álló passzív megfigyelő nem lát bele egy TLS-munkamenetbe, ezért az alagút keveset tesz hozzá egy már HTTPS-t használó oldalhoz, és semmit sem tesz hozzá a két végponthoz. Ezt az állítást az töri meg, aki az eszközt irányítja, mert egy vizsgáló proxy lezárja a kapcsolatot, és újra aláírja egy olyan gyökérrel, amelyben a gép már bízik. Ezért jelenik meg továbbra is a lakat, miközben a tanúsítványlánc annak a szervezetnek a nevét viseli, amely a gyökeret telepítette.

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

macOS-en ez a csővezeték egy tárgysort ír ki a gép kulcskarikájában lévő minden tanúsítványhoz, ablak megnyitása nélkül, Windows-on pedig a certutil -store Root ugyanazt a tárolót listázza, amelyet a certlm.msc grafikusan mutat. Az iskolához, munkáltatóhoz vagy hálózati biztonsági termékhez tartozó gyökér az a bejegyzés, amelyet keresni érdemes. Egy megtalálása csak azt bizonyítja, hogy a lehallgatás lehetséges, nem azt, hogy meg is történik.

Hogy mit tehetsz ellene, politikai és nem technikai kérdés. Egy profil vagy vizsgálógyökér eltávolítása olyan hardverről, amely nem a tiéd, általában megsérti az elfogadható használatról szóló megállapodást, és a felügyeleti rendszer ezt rendszerint észreveszi és újra alkalmazza, ezért az a követelmény, hogy az eszköz tulajdonosa ne olvashassa a forgalmadat, másik eszközt igényel, nem másik beállítást.

Második állítás: senki sem látja, hová mész

A cél a nehezebb állítás, mert két felfedés történik, mielőtt egy oldal betöltődne. A lekérdezés ahhoz a feloldóhoz megy, amelynek használatára a rendszer be van állítva, és a válasz látható annak a hálózatnak, amely szállítja. Ezután a TLS kézfogás a kért kiszolgálónevet nyíltan szállítja, kivéve, ha az Encrypted Client Hello mindkét végén támogatott. Egyik felfedés sem jár titkosítás visszafejtésével, ezért az alagút egyikre sem hat.

resolvectl status | grep -A2 "Link"
nslookup example.com

Hogy melyik feloldót használják valóban, az dönti el a kitettséget, és ez mérhető ahelyett, hogy vitatkoznánk róla. Linuxon a resolvectl status kapcsolatonként kiírja a DNS-kiszolgálókat, és a kimenete megmondja, hogy az oldal feloldója vagy a kényszerített válaszol-e. A Windows ugyanerre a kérdésre a nslookup example.com paranccsal válaszol, amelynek kimenetének első blokkja a válaszoló DNS-kiszolgáló.

Amikor a laptop az oldal feloldóját kérdezi, mielőtt az alagút feláll, vagy a profil helyettesítő kiszolgáló nélkül érkezik, így a régi használatban marad, az adminisztrátor továbbra is gyűjti a gazdagépneveket anélkül, hogy bármit visszafejtene. A böngésző titkosított DNS-e vagy megkerüli a kényszerített feloldót, vagy teljesen blokkolják, és zárt állapotban hibázik. A kimeneti üzemeltető ugyanezeket a neveket látja a maga oldaláról. A feloldó cseréje tehát nem viszi el ezt a felfedést az alagút szolgáltatójától.

Harmadik állítás: senki sem tudja, hogy csatlakoztál

A harmadik állítás az, amelyet egy alagút nem tud alátámasztani, mert a csomagok továbbra is áthaladnak a helyi hálózaton. Az a hálózat megtudja a végpont címét, a hozzávetőleges mennyiséget, az időzítést és egyetlen hosszú életű titkosított munkamenet létezését, ami elég a blokkoláshoz, a korlátozáshoz vagy épp a puszta észleléshez. Egy tűzfal, amely nem tud elolvasni egy csomagot, még mindig megtagadhatja az átengedését. Megfigyeltnek lenni nem ugyanaz, mint hogy senki sem figyel meg: elmozdítottad a megfigyelőt, nem törölted.

A megosztott alagútkezelés és minden olyan alkalmazás, amely figyelmen kívül hagyja a kényszerített útvonalat, olyan folyamokat hoz létre az alagúton kívül, amelyek pontosan úgy néznek ki, mint korábban. Ezeket veszi észre először egy körültekintő megfigyelő, és az ügyfél útvonaltáblázata mutatja, mely célok vannak kizárva.

A másik végén lévő üzemeltető ennek a nézetnek a tükörképét tartja: kilépési cím, időzítés, mennyiség és általában az oldalak nevei. A szolgáltatód lesz az a fél, amelynek rálátása van, ami más üzlet, mint a láthatatlanság. Olyan szolgáltatót választani, amelyben bízol, valódi döntés; a végeredményt megfigyelatlannak nevezni nem az.

Döntsd el, melyik állításra van szükséged

Írd le a követelményt egyetlen sorban, mielőtt hozzányúlsz egy ügyfélhez: rejtsd el a tartalmat, rejtsd el a célokat, vagy rejtsd el, hogy egyáltalán csatlakoztál-e. A tartalmat már a HTTPS és az alagút kezeli, a célok viszont olyan feloldót és útvonalat igényelnek, amelyek teljesen megkerülik az oldal berendezéseit.

A harmadik követelmény a kellemetlen, mert valami még mindig láthatóan kapcsolódik valahol, titkosítva vagy sem. Ezt egyetlen ügyfélbeállítás sem változtatja meg. Ha a követelmény és a szabályzat szétválik, az a rés a szabályzat tulajdonosával folytatott beszélgetésbe tartozik, nem egy ügyfélbeállításba. Aki erre válaszolni tud, az írta a szabályzatot.