Was ist ein DNS- oder WebRTC‑Leck?

Stellen Sie sich DNS als das Telefonbuch des Internets vor. Jedes Mal, wenn Sie eine Web‑Adresse eintippen, kann Ihr Gerät mit dem Namen allein nichts anfangen. Es muss ihn in eine Nummer verwandeln, eine IP‑Adresse, und dafür fragt es einen DNS‑Resolver. In den meisten Netzwerken gehört der Resolver demjenigen, der das Netzwerk betreibt. Zu Hause ist das Ihr Internetanbieter, bei der Arbeit die IT‑Abteilung.

Die kleine Anfrage „Wo ist example.com?“ wandert also zu einem Rechner, den Sie nicht kontrollieren, und sie trägt den Namen der Website mit sich, die Sie gleich öffnen wollen. Ein DNS‑Leck liegt vor, wenn diese Abfrage an dem Schutz vorbeiläuft, auf den Sie sich verlassen. Vielleicht nutzen Sie etwas, das den Datenverkehr selbst verschlüsselt, aber wenn die Namensauflösung weiterhin an den Resolver des Netzwerks hinausgeht, erfährt das Netzwerk trotzdem den Namen jeder Website, die Sie erreichen.

Wichtig ist, was hier eigentlich durchsickert. Ein DNS‑Leck verrät nicht, was Sie gesendet oder gelesen haben. Es verrät, wohin Sie unterwegs waren, und genau das ist für viele Menschen der heikle Teil.

WebRTC ist ein Bündel von Funktionen, das in jeden modernen Browser eingebaut ist, damit Videoanrufe, Sprachchat und mancher direkte Dateiaustausch ohne separate App funktionieren. Um 2 Personen miteinander zu verbinden, muss WebRTC zuerst herausfinden, unter welchen Adressen jeder Teilnehmer erreichbar ist. Es sammelt mögliche Adressen, darunter die lokale Netzwerkadresse Ihres Geräts und, mit Hilfe eines sogenannten STUN‑Servers, Ihre öffentliche IP.

Der Haken: Dieses Sammeln von Adressen kann direkt aus dem JavaScript einer Seite heraus laufen, und es kann einen eigenen Weg nehmen statt den, den der Rest Ihrer Werkzeuge nutzt. Eine Seite kann den Browser also unbemerkt fragen „Wie lautet die echte IP dieses Besuchers?“ und eine Antwort bekommen, selbst wenn die Hauptverbindung abgesichert wirkt.

Das ist ein WebRTC‑Leck. Es kann einer Webseite Ihre echte IP‑Adresse aushändigen, über eine Funktion, die Sie nie eingeschaltet haben. Genau das ist schon Menschen passiert, die dachten, ein einzelnes Werkzeug schütze sie.

Stellen Sie beide nebeneinander. Ein DNS‑Leck nennt dem Netzwerk die Namen der Orte, die Sie besuchen. Ein WebRTC‑Leck nennt einer Website die Nummer, die Ihre Verbindung identifiziert. Auf einem Gerät oder in einem Netzwerk, das jemand anderes kontrolliert, kommt es genau auf diese beiden Angaben an.

Sie greifen ja gerade deshalb zu einem Proxy oder einem Datenschutz‑Tool, um eine dieser 2 Angaben für sich zu behalten. Ein Leck in einem der beiden Kanäle macht diese Mühe zunichte, ohne dass Sie es merken. Nichts wirkt kaputt. Die Seite lädt weiterhin. Sie haben schlicht mehr preisgegeben, als Sie wollten.

• DNS‑Leck: Was durchsickert, ist der Name der Website; wer ihn sieht, ist das Netzwerk (Ihr Internetanbieter oder der lokale Resolver); erkennen lässt es sich mit einem DNS‑Leck‑Test.
• WebRTC‑Leck: Was durchsickert, ist Ihre echte IP‑Adresse; wer sie sieht, ist die Website, die Sie gerade besuchen; erkennen lässt es sich mit einem WebRTC‑Leck‑Test.

Hier verdient sich ein Web‑Proxy, der Seiten umschreibt, seinen Platz, und hier lohnt es sich, genau hinzusehen, was er tut und was nicht.

Wenn Sie eine Website über TrickyBird öffnen, laden Sie in Wirklichkeit TrickyBirds eigene Adresse. Die Adresse des Ziels ist im Pfad kodiert, und den Namen der Website lösen wir bei uns auf; Ihr Gerät fragt nach unserer Adresse. Wenn Sie sich also fragen, was ein Web‑Proxy hier für Sie tut: Er verbirgt Ihre IP‑Adresse vor der Website, die Sie öffnen, und löst deren Namen selbst auf. Es ist derselbe Schutz vor Domain‑Leaks: Überall dort, wo die Adresse des Ziels mitgeführt werden muss, wird sie kodiert statt ausgeschrieben mitgeführt (auf /status sehen Sie, welche Websites derzeit sauber dargestellt werden). Es gibt keinen Download und keine App, und genau darauf kommt es an, wenn die Sperre auf einem Gerät sitzt, das Sie nichts installieren lässt.

Eine ehrliche Grenze sollte man klar benennen. Das Gateway selbst muss das Ziel weiterhin auflösen und sich mit ihm verbinden, um es abzurufen, dieser Teil der Strecke ist also nicht verborgen. Wir führen darüber bewusst nur einen kleinen Eintrag: eine gekürzte IP‑Adresse, gestutzt auf ein /24 oder /48, sodass sie auf eine Nachbarschaft statt auf ein einzelnes Haus zeigt, dazu den Ziel‑Hostnamen und grundlegende Antwortdetails, für höchstens 48 Stunden. Alle Details zu Aufbewahrung und Löschung stehen auf /security. Das ist überprüfbare, minimale, kurzlebige Protokollierung, und entscheidend ist, dass Sie sie prüfen können, statt sich auf unser Wort zu verlassen. Das ist eine ganz andere Haltung als ein absolutes Versprechen, das Sie nicht nachprüfen können. So schneiden die Richtlinien im Vergleich ab.

Nein, und hier sollte man genau sein. TrickyBird schreibt die Seiten um, die es ausliefert, aber es fängt WebRTC nicht ab. WebRTC läuft als eigenes Browser‑Subsystem über seinen eigenen Netzwerkweg, sodass eine Seite, die Sie über den Proxy öffnen, weiterhin direkt einen STUN‑Server erreichen und Ihre echte IP zurückbekommen kann, selbst während der Rest dieser Seite über TrickyBird lädt.

Behandeln Sie WebRTC also als etwas, das Sie selbst abschalten, nicht als etwas, das der Proxy für Sie übernimmt. Schalten Sie es in Ihrem Browser mit den Schritten weiter unten ab und machen Sie dann auf genau dem Gerät und in genau dem Netzwerk, auf die es Ihnen ankommt, einen WebRTC‑Leck‑Test, um zu bestätigen, dass Ihre echte IP nicht mehr auftaucht. Prüfen Sie es lieber selbst, als irgendeiner Behauptung zu vertrauen, auch dieser hier.

Sie müssen sich nicht auf ein einzelnes Werkzeug verlassen. WebRTC lässt sich auch im Browser selbst zurückfahren, und das zu wissen lohnt sich. In Firefox können Sie about:config öffnen und media.peerconnection.enabled auf false setzen, das schaltet die Funktion ab. Chrome bietet keinen eigenen Schalter, deshalb greifen viele zu einer gut bewerteten Erweiterung, die WebRTC blockiert, wobei Sie auf einem verwalteten Gerät womöglich keine hinzufügen dürfen.

Auf dem Handy kommt es auf die Plattform an. Safari unter iOS ist restriktiver dabei, was WebRTC an eine Seite herausgibt, während sich Chrome unter Android weitgehend wie am Computer verhält. Wenn Sie sich also fragen, ob auch iOS über WebRTC etwas preisgibt: Ja, aber weniger freigiebig als ein Browser am Computer.

Auch für DNS gibt es eine erwähnenswerte Einstellung im Browser. DNS over HTTPS, kurz DoH, schickt Ihre Abfragen über einen verschlüsselten Kanal an einen Resolver statt an den Standard‑Resolver des Netzwerks; hier fangen viele an, wenn sie zum ersten Mal über DNS‑Lecks lesen. Nichts davon ersetzt das Testen. Probieren Sie diese Einstellungen aus, und prüfen Sie danach das Ergebnis.

Sie müssen keinem Werbeversprechen glauben, und das sollte auch niemand von Ihnen verlangen. Ein Leck‑Test dauert etwa eine Minute. Öffnen Sie eine DNS- und WebRTC‑Leck‑Testseite, einen neutralen Prüfdienst wie browserleaks.com oder ipleak.net: Sie zeigt Ihnen, welche Resolver Ihre Abfragen erreichen und welche öffentliche IP eine Seite von Ihnen sehen kann, WebRTC eingeschlossen.

Machen Sie das einmal in dem Netzwerk, auf das es Ihnen wirklich ankommt. Steht dort der Resolver Ihres Internetanbieters oder des lokalen Netzwerks, sickert Ihr DNS durch. Ist die angezeigte öffentliche IP Ihre eigene Adresse, gibt WebRTC oder die Verbindung sie preis. Schalten Sie Ihr Werkzeug ein und wiederholen Sie die Prüfung, um zu sehen, ob sich die Zahlen ändern.

TrickyBirds /proof-Seite prüft etwas anderes, und beide sollten Sie auseinanderhalten. Sie führt Sie durch das, was mit der Adresse der Website, die Sie öffnen, tatsächlich geschieht: In der Adressleiste und in den Referer- und Origin‑Headern, die Ihr Browser sendet, steckt sie kodiert in unserer eigenen Adresse statt ausgeschrieben, und im Seitenquelltext steht sie an der einen Stelle, die die Seite Ihnen nennt. Das ist eine Prüfung auf Domain‑Leaks, nicht auf DNS- oder WebRTC‑Lecks, und sie zeigt keine IP an und sagt Ihnen nicht, ob WebRTC Ihre preisgibt. Nutzen Sie dafür eine der Leck‑Testseiten oben und schalten Sie WebRTC in Ihrem Browser ab. Ein Werkzeug, das etwas taugt, übersteht es, wenn jemand die Entwicklertools öffnet und nachsieht. Denselben Maßstab sollten Sie an jeden kostenlosen Web‑Proxy anlegen, auch an unseren.

Hier finden Sie die Grundlagen zu diesem Thema.

• Was ist ein Web‑Proxy?
• Web‑Proxy vs. VPN
• Ist die Nutzung eines Proxys legal?
• Eine Website entsperren
• Unsere Logging- und Sicherheitsrichtlinie