WebRTC-IP-Leak-Detektor

Ein WebRTC-IP-Leck tritt auf, wenn die RTCPeerConnection-API des Browsers eine IP-Adresse enthält – typischerweise die echte lokale oder öffentliche IP – die ein VPN oder Proxy verstecken sollte. Da WebRTC die normale HTTP-Stack umgeht, um Peer-to-Peer-Kandidaten zu sammeln, wird das Routing des Browsers durch ein VPN nicht automatisch durch das VPN-Verbindung routiert. Wenn sowohl eine öffentliche IP als auch eine nicht verdeckte lokale IP an JavaScript übermittelt werden, kann ein Skript auf einer Website die echte Netzwerk-IP hinter dem Tunnel erkennen.

ICE (Interactive Connectivity Establishment) ist das Verhandlungsframework, das WebRTC verwendet, um einen geeigneten Weg zwischen zwei Benutzern zu finden. Jeder ICE-Kandidat beschreibt eine mögliche Adresse, an der ein Peer erreicht werden kann, einschließlich eines Typs: Host (lokale Schnittstelle), srflx (server-reflexiv, über STUN entdeckt) oder Relay (über einen TURN-Server). Ein STUN-Server (Session Traversal Utilities for NAT) ist ein leichtgewichtiger öffentlicher Dienst, der die öffentliche IP und Port zurückgibt, an dem eine Verbindung eingetroffen ist – so lernt der Browser seine eigene externe Adresse, wenn er hinter einem NAT steht.

Neue Builds von Chrome und Firefox ersetzen die rohen lokalen IPv4-Adressen in Host-Kandidaten durch einen zufälligen Hostnamen, der mit .local endet, wie beispielsweise a1b2c3d4-5678-90ab-cdef-1234567890ab.local. Diese mDNS-Hostnamen sind nur auf dem lokalen Netzwerksegment während einer tatsächlichen Peer-Verhandlung erreichbar – sie sind für JavaScript und für Dritte STUN-Server unverständlich. Das bedeutet, dass ein Skript die 192.168.x.y oder 10.x.y.z LAN-Adresse des Benutzers nicht mehr einfach aus einem ICE-Kandidaten ablesen kann.

Nicht grundlegend. Die öffentliche IP ist bereits für alle HTTP-Server sichtbar, die der Browser kontaktiert. Ein von einem STUN-Server entdeckter srflx-Kandidat enthält daher in einem normalen Browserkontext nichts Neues. Das Problem ist spezifisch für die Privatsphäre: Wenn der Benutzer hinter einem VPN oder einem Datenschutz-Tool ist, das seine echte öffentliche IP verstecken soll, und WebRTC einen srflx-Kandidaten mit der echten öffentlichen IP statt der VPN-Exit-IP zeigt, dann ist das ein Leck. Die Bewertung ändert sich mit dem Zweck – der gleiche Kandidat kann entweder harmlos oder ein Leck sein, abhängig davon, ob ein VPN aktiv ist.