Ein Proxy deckt oft HTTP-Verkehr ab, während WebRTC über STUN/ICE per UDP Kandidatenadressen austauscht. Der Beitrag erklärt, wann lokale und interne Adressen sichtbar werden und wie Netzwerkausgang und Browserumgebung konsistent bleiben.
Der Proxy ist eingerichtet, und eine IP-Abfrage zeigt die erwartete Region und den richtigen Anbieter. Die Netzwerkidentität wirkt sauber. Öffnet man jedoch einen Leak-Test, ist der WebRTC-Bereich rot und zeigt die Adresse des tatsächlichen Internetzugangs.
Ein Wechsel des Proxys ist deshalb nicht unbedingt nötig. Meist liegt das Problem nicht an seiner Qualität, sondern an Datenverkehr, den er nicht erfasst.
Der Proxy behandelt HTTP, WebRTC nimmt einen anderen Weg
Ein Proxy arbeitet auf der Netzwerkebene. Ob als Browser-Erweiterung oder systemweiter Tunnel: Er verarbeitet HTTP/HTTPS-Anfragen und leitet diesen Verkehr über den Proxy-Ausgang.
WebRTC funktioniert anders. Es ist eine im Browser integrierte Echtzeitkommunikation. Damit Audio-/Videoanrufe und P2P-Übertragungen einen geeigneten Pfad finden, kann der Browser aktiv STUN-Anfragen an externe Server senden – sinngemäß: „Welche Adresse siehst du von mir?“ – und die Antworten anschließend als ICE-Kandidaten an die Webseite weitergeben. Diese Anfragen laufen über UDP und damit über einen vom HTTP-Tunnel unabhängigen Kanal.
So entsteht eine Lücke: Webseitenanfragen gehen über den Proxy, während der Browser gleichzeitig eine lokale Adresse melden kann. Die Annahme, dass ein eingerichteter Proxy automatisch die gesamte Netzwerkidentität bereinigt, ist der häufigste Ausgangspunkt dieses Problems.
Nicht nur die öffentliche IP kann offengelegt werden
ICE-Kandidaten enthalten üblicherweise zwei Arten von Adressen. Die eine ist die öffentliche Adresse, also der Ausgang des tatsächlichen Internetanbieters. Die andere ist eine lokale Adresse, zum Beispiel eine interne Adresse, die mit 192.168 beginnt; manchmal erscheinen auch Adressen virtueller Netzwerkadapter.
Eine interne Adresse sagt für sich genommen wenig aus, denn fast jeder Rechner besitzt eine. Sie kann jedoch stabil genug sein, dass wiederkehrende Überschneidungen der Kandidatenadressen bei mehreren Konten einer Plattform ein weiteres Signal liefern, diese demselben Gerät zuzuordnen. Eine öffentliche Adresse ist direkter: Sie weist auf den tatsächlichen Anbieter und eine ungefähre geografische Region hin. Wie fein die Zuordnung wird, hängt von der Plattform ab; grundsätzlich gilt aber: Je echter die Adresse, desto einfacher die Verknüpfung.
Wann kann eine Website die Adresse tatsächlich lesen?
Nicht jede Website versucht das. Für den Adressaustausch muss die Seite aktiv ein RTCPeerConnection-Objekt erzeugen; gewöhnliche Inhaltsseiten benötigen das meist nicht.
Typisch ist es eher bei Diensten mit Echtzeitkommunikation, etwa Videokonferenzen, Online-Support und manchen Livestream-Seiten, bei Angeboten mit starkem Fokus auf Werbung oder Betrugsprävention sowie bei Plattformen mit ausgebauten Risikokontrollen. Das Auslesen geschieht außerhalb der sichtbaren Oberfläche, und über die spätere Nutzung der gesammelten Daten erhält man normalerweise keine Benachrichtigung.
Daneben gibt es einen Fall, der nicht von der Website abhängt. Während eines kurzen Moments beim Neuverbinden des Proxys oder beim Wechsel des Knotens kann eine STUN-Anfrage des Browsers über das lokale Netzwerk laufen. Das Zeitfenster ist klein, reicht aber für eine einzelne Erfassung aus.
Drei häufige Fehlerszenarien
Browser-Erweiterungen als Proxy übernehmen meist nur HTTP/HTTPS-Anfragen. UDP liegt außerhalb ihres Zuständigkeitsbereichs; auch eine als „global“ bezeichnete Einstellung ändert daran nichts.
Ein systemweiter Proxy wirkt vollständiger, weil er den Verkehr des gesamten Geräts abdeckt. Die Erfassung von Kandidatenadressen kann jedoch direkt an eine lokale Netzwerkschnittstelle gebunden sein und die System-Routingtabelle umgehen. An dieser Stelle bleibt der Tunnel lückenhaft.
Das dritte Problem ist weniger technischer als zeitlicher Natur. Risikokontrollsysteme berücksichtigen WebRTC-Adressen zunehmend als eines von mehreren Signalen zur Verknüpfung von Konten. Daten, die früher nicht gemessen oder ignoriert wurden, können heute in eine Bewertung einfließen.
Entscheidend ist ein konsistenter Ausgang, nicht nur ein deaktivierter Schalter
Es gibt mehrere grundsätzliche Ansätze. Wird Echtzeitkommunikation im jeweiligen Ablauf überhaupt nicht benötigt, ist das Deaktivieren von WebRTC am einfachsten. Dafür funktionieren dann auch Funktionen wie Videoanrufe oder Online-Support nicht mehr.
Müssen diese Funktionen erhalten bleiben, wird häufig dafür gesorgt, dass die auf WebRTC-Ebene zurückgegebene Adresse zum Proxy-Ausgang passt. Robuster ist es, auch STUN-Anfragen über den Proxy-Kanal weiterzuleiten, sodass an der Schnittstelle keine lokale Adresse sichtbar wird. Werden P2P oder Videoanrufe benötigt, sollte der gesamte UDP-Verkehr über den Proxy laufen und nicht nur die HTTP-Schicht.
Ein häufiger Irrtum ist, dass das bloße Abschalten von WebRTC die Umgebung bereits sauber mache. Entscheidend ist die gegenseitige Konsistenz von Netzwerkausgang, DNS-Auflösung, IP-Zuordnung und ASN, Zeitzone und Sprache sowie Gerätemerkmalen. Jede Abweichung kann ein Auffälligkeitssignal erzeugen; WebRTC ist nur einer der Punkte, die besonders leicht übersehen werden.
Die Überprüfung ist einfach. Nach einem Knotenwechsel und noch einmal vor dem regulären Einsatz einen Leak-Test öffnen und prüfen, ob im WebRTC-Bereich der Proxy-Ausgang, eine lokale Adresse oder die echte öffentliche Adresse erscheint. Eine normale IP-Abfrage zeigt diesen Punkt nicht.
Eine Umgebungsisolation auf Browser-Engine-Ebene kann für jede Umgebung eine eigene WebRTC-Adressstrategie festlegen und sie mit dem zugehörigen Netzwerkausgang verbinden. PurpleMark bietet genau diese Art von Funktion. Nutzen mehrere Umgebungen denselben Ausgang oder widersprechen sich ihre Adressstrategien, verliert die Isolation deutlich an Wirkung.
Dies ist lediglich eine technische Erläuterung. Verwenden Sie entsprechende Werkzeuge unter Beachtung der Plattformregeln und der geltenden lokalen Gesetze.
