Láthatja a VPN üzemeltetője, mely oldalakat nyitja meg?

Kérdezze meg, mit lát a VPN, és a válasz attól függ, hol áll az útvonalon. A munkamenet rétegén az üzemeltetőnek hitelesítési eseményei és bájtszámai vannak. A csomagok rétegén célcímekkel és időzítéssel rendelkezik. A DNS rétegén maguk a nevek is meglehetnek. Minden réteg más kérdésre válaszol, és egyetlen kapcsoló sem viszi át egyikből a másikba.

Állítás előtt határozza meg a réteget

Ugyanaz a kapcsolat minden ponton más nyilvántartást hoz létre, és az adatvédelemről szóló kijelentés csak akkor értelmes, ha megnevezi a pontot. Olvassa végig a táblázatot oszloponként: mi létezik azon a rétegen, mit láthat ott az üzemeltető, és mit nem mondhatnak el ugyanezek a nyilvántartások.

Egyetlen réteget az egész képként olvasni vezet a túlzó állításokhoz és a hamis biztonságérzethez is. Egy szolgáltató, amely azt mondja, nem naplóz böngészést, helyes lehet az URL-naplózás kérdésében, miközben munkamenet-nyilvántartásokat mégis tárol, és a csak címeket mutató csomagrögzítésből fordított keresések és találgatás nélkül nem lesz böngészési előzmény.

Amikor szabályzatot értékel, keresse meg a mondatot, amely az egyes rétegeket leírja. Ha a szabályzat nem választja szét őket, kérdezze meg, milyen nyilvántartások léteznek, ahelyett hogy elfogadna egy általános kijelentést a titkosításról.

Munkamenet-leltár: mit tart meg egy alap OpenVPN kiszolgáló

Alapbeállítás szerint az OpenVPN kiszolgáló nem rögzít forgalmat. A szokásos kimenet egy munkamenet-leltár: melyik fiók hitelesítette magát, milyen forrásból érkezett, a kezdet és a vég időbélyegei, a kiadott csatornacím és a két irány bájtszámai. Ez a munkamenetek leltára, nem a célállomások listája.

A naplózási lehetőségek részleteket adhatnak. A magasabb részletességi szint többet ír a kézfogásról, az állapotfájl pedig felsorolhatja a csatlakozott klienseket, de egyik sem változtatja a kiszolgálót átlátszó proxyvá. URL-ek előállításához a TLS lezárása vagy külön proxy futtatása kell, és mindkettő a bizalmi viszonyt változtatja meg, nem egy rejtett funkciót kapcsol be.

Ezért a nincs böngészési napló állítás pontos változata szűkebb annál, mint amilyennek hangzik. A kiszolgáló nem ismeri az oldalt, de tudja, hogy létezett egy munkamenet, és nagyjából mennyi adat haladt át rajta. Hogy ezt a munkamenet-nyilvántartást megőrzik-e, és meddig, az külön szabályozási kérdés.

A belső és a külső csomagok különböző bizonyítékok

Csomagrögzítéssel látja, mi halad át valójában a csatornán. A kiszolgálón nevezze meg az alagút interfészét, és írjon olyan fájlba, amely később offline elemezhető:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

A fájl a visszafejtett belső forgalmat tartalmazza: forrásként a kliens csatornacímét, a célcímet és portot, a csomagok méretét és idejét. Nem tartalmazza az HTTP-útvonalat vagy a válasz törzsét, hacsak valahol nem zárták le a TLS-t, és ez érzékeny adat, amelynek megőrzése szabályozási döntés, nem hibakeresési kényelem.

A fizikai interfészen készült rögzítés mást mutat. Ott a VPN végponthoz címzett külső csomagokat lát, bennük a titkosított tartalommal. A fájlban megjelenő, oda nem tartozó címek normálisak, ha létezik virtuális adapter, mert az alagút-eszköz a belső folyamokat, a titkosított átvitel a külsőket szállítja.

Kérdezze meg, milyen kérdésre kell a rögzítésnek válaszolnia. Egy alkalmazás alagút-használata a virtuális adapteren látszik; az alagút elérhetősége a végpont felé a fizikai adapteren. Bármelyik fájlt teljes képként kezelni olyan következtetéseket ad, amelyeket az adatok nem támasztanak alá.

A DNS az a hely, ahol a nevek láthatóvá válnak

A DNS marad a gyakorlati kivétel. A feloldó látja a neveket, amelyeket fel kell oldania, így aki üzemelteti, megtudja, mely oldalakat keresi a kliens, még akkor is, ha a későbbi kapcsolatok titkosítottak. A csatorna rögzítése címeket mutat; a feloldó neveket.

Ellenőrizze, melyik címmel érte el a feloldó a külső szolgáltatást. A válasz a feloldó kimenő címe, és a VPN-kilépéssel összevetve kiderül, átment-e a lekérdezés az alagúton:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

Ha ez a cím a helyi kapcsolattal egyezik, nem a csatorna kilépésével, akkor a keresés megkerülte a VPN-t, és a név a helyi útvonalon látható volt. Ismételje meg az ellenőrzést a kliens frissítése után, mert az új verzió megváltoztathatja, melyik feloldót telepíti a profil.

A titkosított DNS áthelyezi a láthatóságot, nem megszünteti. A hálózat már nem látja a lekérdezést, a feloldó viszont igen, és a bizalmi kérdés egyszerűen gazdát cserél. A kapcsolat kézfogásában szereplő TLS-kiszolgálónév egy újabb részleges jel: gyakran túléli azt is, amikor a tartalom átlátszatlan, így a célcímek nem az egyetlen metaadatok, amelyeket egy továbbító kiszolgáló megfigyelhet.

Három nyilvántartástípus, és hogy ki olvashatja őket

A munkamenet-elszámolás, a névenkénti nyilvántartások és a szivárgási bizonyítékok három különböző termék, három különböző kötelezettséggel. A munkamenetnaplók olcsók és kevéssé érzékenyek, és megválaszolják, ki kapcsolódott és mikor. A névenkénti nyilvántartásokhoz naplózó feloldó vagy külön proxy kell, és közzétételi kötelezettséget teremtenek az érintettek felé. A szivárgási bizonyíték kliensoldali vizsgálat, amely összeveti, mit árul el a feloldó, a csatorna kilépésével.

Jegyezze fel, melyiket futtatja a három közül, ki olvashatja, és meddig marad meg. Azok az állítások, hogy egy szolgáltatás nem vezet naplót, egy réteget írnak le, és csak ezen a területen maradnak igazak. Ugyanaz a szolgáltató helyes lehet a munkamenetekről, és tévedhet a DNS-ről.

Tartsa a vizsgálatot megismételhetőnek: ugyanaz a feloldó-lekérdezés, ugyanaz a rögzítő interfész és ugyanaz az összevetés. Az adatvédelmi állítás, amely megnevezett rétegen nem vizsgálható, szlogen, nem működési tény.