WebRTC-Leaks: Warum Ihre echte Adresse selbst hinter einem Proxy sichtbar sein kann
WebRTC gibt es, damit Browser für Anrufe und Bildschirmfreigabe direkt miteinander sprechen können. Dafür müssen sie herausfinden, unter welchen Adressen sie erreichbar sind, und dieser Ermittlungsprozess ist gemeint, wenn von einem „WebRTC-Leak“ die Rede ist.
ICE-Kandidaten in einem Absatz
Erstellt eine Seite eine RTCPeerConnection und startet ein Angebot, sammelt der Browser Kandidaten: Wege, auf denen ein anderer Peer ihn erreichen könnte. Ein Host-Kandidat ist die Adresse einer lokalen Schnittstelle. Ein Server-Reflexive-Kandidat (srflx) ist die öffentliche Adresse, von der ein STUN-Server die Anfrage eintreffen sah. Ein Relay-Kandidat ist die Adresse eines TURN-Servers. Jeder Kandidat wird der Seite als Textzeile übergeben, die die Adresse enthält, und so kann ein Skript sie lesen, ohne dass je ein Anruf zustande kommt.
Wo das Leak liegt
Der srflx-Kandidat ist der, auf den es ankommt. Um ihn zu erhalten, sendet der Browser ein kleines UDP-Paket an einen STUN-Server, der mit der Adresse antwortet, die er gesehen hat. Läuft Ihr HTTP-Verkehr über einen Proxy, Ihr UDP-Verkehr aber nicht, sieht der STUN-Server Ihre echte Verbindung, und die Seite besitzt nun eine Adresse, die der widerspricht, die der Webserver gesehen hat. Dieser Widerspruch ist das klassische Leak. Eine Diagnoseseite kann es zeigen, indem sie beide vergleicht.
Beachten Sie, was geschieht und was nicht. Es werden keine Medien aufgenommen. Es ist keine Mikrofon- oder Kameraberechtigung beteiligt. Das Paket geht an den STUN-Server, den die Seite benannt hat, sodass dieser Server wie jeder Server, den Sie kontaktieren, Ihre Adresse sieht.
Was Browser geändert haben
Host-Kandidaten legten früher private LAN-Adressen wie 192.168.1.23 offen, die sich zum Fingerprinting eines Heimnetzwerks eigneten. Moderne Browser ersetzen sie durch zufällig erzeugte mDNS-Namen, die auf .local enden, sodass eine Seite einen undurchsichtigen Namen statt einer Adresse sieht. Eine Diagnose, die „vom Browser maskiert“ meldet, beschreibt genau diese. Firefox und Brave bieten außerdem Einstellungen, die das Sammeln von Kandidaten außerhalb des Proxys unterbinden, und manche Erweiterungen blockieren WebRTC vollständig.
Proxy-sichere Konfigurationen
Drei Ansätze funktionieren, mit unterschiedlichen Kosten. WebRTC zu deaktivieren verhindert das Leak und bricht jede Seite, die es braucht. WebRTC zu zwingen, nur die Route des Proxys zu nutzen (der „proxy-sichere“ Modus in manchen Browsern), hält Anrufe am Laufen, wenn der Proxy UDP oder TURN unterstützt, und liefert sonst überhaupt keinen öffentlichen Kandidaten. WebRTC sich normal verhalten zu lassen ist nur dann richtig, wenn der Proxy den gesamten Verkehr trägt, wie es ein VPN auf Systemebene meist tut.
Welcher Ansatz passt, hängt von der Aufgabe ab. Für ein isoliertes Browserprofil, das an einem einzigen Ort zu sein scheinen muss, ist die Regel einfach: Die Adresse, die WebRTC preisgibt, muss dieselbe sein, die der Webserver sieht, oder gar keine. Alles andere ist ein Widerspruch, den eine Seite ohne besondere Werkzeuge bemerken kann.
Das Ergebnis lesen
Eine Diagnose zeigt die innerhalb weniger Sekunden beobachteten Kandidaten und vergleicht jeden öffentlichen mit der Adresse, von der die Seite aufgerufen wurde. „Keine offengelegt“ mit einigen maskierten Kandidaten ist ein normales, gesundes Ergebnis für einen Browser, der WebRTC innerhalb des Proxys hält. Eine öffentliche Adresse, die von der Adresse der Seite abweicht, ist das, was behoben werden muss.
