Kliens IP és WebRTC szivárgás teszt

A „WebRTC szivárgás” egy jól ismert adatvédelmi rés: ugyanaz a böngésző API, amely a videohívásokat és a peer-to-peer fájlátvitelt lehetővé teszi, közvetlen kapcsolatot is tárgyal két böngésző között, és ez a tárgyalási folyamat olyan IP-címeket is felfedhet, amelyek egy hétköznapi HTTP-kérésben soha nem jelennek meg. Ez az eszköz mindkét ellenőrzést egymás mellett futtatja — azt a puszta publikus IP-címet, amit egy weboldal a HTTP-kéréseidből lát, és azokat a címeket, amelyeket a böngésződ WebRTC rétege a kapcsolat felépítése közben felfed —, így összehasonlíthatod őket, és láthatod, felfedődik-e valami, amire nem számítottál.

A publikus IP szakasz két lekérdezést végez: egy szigorúan csak IPv4-et kérő lekérdezést, és egyet, amely azt a címcsaládot adja vissza, amit a kapcsolatod ténylegesen előnyben részesít — ez lehet IPv6 cím is, ha a hálózatod natívan támogatja azt. Ez az a cím, amellyel egy hétköznapi weboldal, és mindenki, akivel az naplókat oszt meg, a kapcsolódásodat látja.

A WebRTC szakasz egy helyi kapcsolatkísérletet indít a szabványos ICE jelöltgyűjtési folyamat segítségével (ugyanaz a mechanizmus, amit egy videohívó alkalmazás használ a két fél közötti legjobb útvonal megtalálásához), és felsorolja az összes egyedi címet, amely előkerül, jelölttípus szerint megcímkézve: a „host” jelöltek a saját géped hálózati interfészeiből származnak, az „srflx” (server-reflexive) jelöltek egy STUN szervertől érkeznek vissza, és jellemzően megegyeznek a publikus IP-ddel, a „relay” jelöltek pedig egy TURN szerveren keresztül haladnak. A valódi IP-címet tartalmazó host jelölt — a böngésző által generált „.local” helyettesítő helyett — a klasszikus szivárgás: felfedheti a tényleges LAN IP-címedet még akkor is, ha egy VPN egyébként megfelelően elrejti a publikus IP-det mindenhol máshol.

A Chrome és a Firefox modern verziói ennek egy részét úgy mérséklik, hogy a host jelöltekben a valódi helyi IP helyett egy véletlenszerű, munkamenetenkénti „.local” hosztnevet adnak meg, amely csak a saját hálózatodon, mDNS-en keresztül oldható fel, ahelyett hogy a szó szerinti címet tárnák fel az oldal előtt. Ez az eszköz külön jelzi ezt az esetet, mivel ez azt jelenti, hogy a szivárgást már a böngésződ mérsékelte, nem a VPN-ed vagy a hálózati konfigurációd — egy valódi, host típusú IP-cím megjelenése az, amit érdemes kivizsgálni.

Mindkét ellenőrzés valódi hálózati aktivitást igényel: a publikus IP lekérdezéshez élő HTTP-kapcsolat kell egy lekérdező szolgáltatáshoz, a WebRTC vizsgálathoz pedig el kell érni egy publikus STUN szervert a reflexív cím felderítéséhez, így ez az egyik azon kevés eszköz közül ebben az eszköztárban, amely nem működik teljesen offline. Az eredményeid nem kerülnek sehova tárolásra — az oldal egyszerűen megmutatja, amit a saját böngésződ és hálózati rétege felfed, ugyanúgy, ahogy bármely más meglátogatott weboldal is megfigyelhetné.