WebRTC interessiert dein Proxy nicht

Warum es überhaupt passiert

WebRTC gibt es, damit Browser direkt miteinander sprechen können — Videoanrufe, Sprache, Peer-to-Peer-Daten — ohne alles über einen Server zu leiten. Direktverbindungen sind der ganze Zweck, und um eine herzustellen, muss dein Browser herausfinden, unter welchen Adressen er erreichbar ist.

Dazu fragt er einen STUN-Server. Der Browser schickt ein UDP-Paket an einen öffentlichen STUN-Endpunkt, und der Server antwortet mit der Quelladresse, die er gesehen hat. Das ist deine öffentliche IP, zurückgespiegelt und JavaScript als ICE-Kandidat übergeben.

Der entscheidende Punkt: Das läuft über UDP, außerhalb des HTTP-Pfads. Ein im Browser eingerichteter HTTP- oder SOCKS-Proxy kümmert sich um HTTP-Verkehr. Das STUN-Paket nutzt ihn nicht. Deine Seiten laden über den Proxy, deine WebRTC-Ermittlung nicht, und nirgends meldet irgendetwas ein Problem.

Das unterscheidet diesen Fehlerfall von allen anderen. Ein kaputter Proxy erzeugt Fehler. Ein WebRTC-Leak erzeugt Stille.

Was eine Seite tatsächlich sieht

Der ganze Angriff ist kurz genug, um ihn in einem Zug zu lesen:

const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createDataChannel('');
pc.createOffer().then(o => pc.setLocalDescription(o));

Jede Kandidatenzeile enthält eine Adresse und einen Typ. Drei Typen zählen:

Weicht die srflx-Adresse von der Adresse ab, aus der deine HTTP-Anfragen kommen, hast du der Seite einen Widerspruch geschenkt, für den sie nichts tun musste: Die Seite hält dich für Frankfurt, WebRTC sagt Mailand.

mDNS löst die kleinere Hälfte

Chrome liefert seit Version 76 mDNS-Verschleierung für lokale Adressen aus. Statt 192.168.1.42 erscheinen Host-Kandidaten als zufällige UUID mit der Endung .local. Das ist wirklich gut und standardmäßig aktiv.

Es wird auch häufig missverstanden. mDNS betrifft nur host-Kandidaten — deine LAN-Adresse. Für srflx-Kandidaten, die deine öffentliche IP tragen, tut es nichts. Anleitungen, die dir sagen, du sollst chrome://flags/#enable-webrtc-hide-local-ips-with-mdns einschalten und das Problem sei gelöst, beschreiben eine Lösung für die unwichtigere Hälfte.

Auch hier gibt es ein Signal zweiter Ordnung. Der verschleierte .local-Hostname bleibt für die Sitzung stabil, und die Anzahl der Host-Kandidaten spiegelt wider, wie viele Netzwerkschnittstellen die Maschine hat. Ein Profil, das sechs Schnittstellen meldet, sieht aus wie eine Maschine mit mehreren VPN-Adaptern — nicht wie ein gewöhnlicher Laptop.

Vier Umgangsweisen

Antidetect-Browser bieten meist eine Variante dieser vier an. Sie sind nicht gleich gut, und die beste hängt davon ab, was du vorhast.

Vollständig deaktiviert

Kein RTCPeerConnection, keine Kandidaten, kein Leak. Sauber, aber erkennbar: WebRTC ist seit einem Jahrzehnt in jedem Browser Standard, und ein Chrome ohne ist ungewöhnlich. In Ordnung für Accounts, die nie Anrufe oder Streaming anfassen. Falsch für alles, was das tut — manche Seiten nutzen die Präsenz von WebRTC inzwischen als Lebendigkeitsprüfung.

UDP deaktiviert

Die API existiert und antwortet, aber es geht kein UDP hinaus, also entsteht kein srflx-Kandidat. Weniger auffällig als vollständiges Entfernen, und das Leck ist tatsächlich zu. Es bricht auch echte WebRTC-Funktionalität, was zählen kann oder nicht.

Real

Alles unangetastet durchreichen. Das ist in genau einer Situation richtig: wenn dein Proxy auch UDP übernimmt. Ein SOCKS5-Proxy mit UDP-Association oder ein systemweites VPN leitet das STUN-Paket über denselben Ausgang wie deinen HTTP-Verkehr, und die zurückgespiegelte Adresse ist die des Proxys. In diesem Aufbau ist echtes WebRTC die authentischste verfügbare Option. Prüfe das nach, statt es anzunehmen.

Verändert

Ersetze die ermittelte öffentliche Adresse durch den Proxy-Ausgang, bevor sie JavaScript erreicht. WebRTC funktioniert weiter, Kandidaten sind in üblicher Zahl vorhanden, und sie passen zum HTTP-Pfad. Das ist die überzeugendste Konfiguration, wenn sie auf Engine-Ebene erfolgt — die Ersetzung muss dort geschehen, wo Kandidaten erzeugt werden, nicht in einem Content-Skript, sonst widersprechen sich beide und du bist wieder am Anfang.

Richtig testen

Die meisten „WebRTC-Leaktests“ melden nur, ob eine öffentliche Adresse aufgetaucht ist. Das ist nicht die Frage. Die Frage ist, ob sie zu deinem Proxy passt.

Das verlässliche Vorgehen dauert zwei Minuten:

1. Notiere die Ausgangsadresse, die der Proxy dir geben soll.
2. Lade browserleaks.com/webrtc im Profil und lies die Zeile mit der öffentlichen IP.
3. Vergleiche. Gleich ist gut. Anders ist ein Leak, selbst wenn die andere Adresse nicht deine Heim-IP ist — eine Rechenzentrumsadresse neben einem Residential-HTTP-Pfad ist für sich schon ein Widerspruch.
4. Wiederhole es mit abgeschaltetem Profil-Proxy. Ändert sich der Wert nicht, läuft WebRTC überhaupt nicht über den Proxy, und die vorherige Übereinstimmung war Zufall.

Diesen vierten Schritt lassen die meisten aus — und genau er deckt eine Fehlkonfiguration auf.

Wo es im Gesamtbild steht

WebRTC hat seinen Ruf verdient, aber man sollte es im Verhältnis sehen. Es ist ein Signal, und eines der leichter dauerhaft zu schließenden: einmal pro Profil einstellen, einmal prüfen — und es bleibt erledigt.

Was es nicht ist: ein Ersatz für den Rest. Ein Profil mit perfekter WebRTC-Behandlung und unstimmigem Fingerprint fliegt an der Unstimmigkeit auf. Ein Profil hinter einem Rechenzentrums-Proxy fliegt an der ASN auf, ob WebRTC leckt oder nicht.

Der Grund, es zuerst zu beheben, ist nicht, dass es das wichtigste Signal wäre. Es ist das einzige, das lautlos versagt, und lautlose Fehler erfährt man aus einer Sperr-E-Mail.