Am 4. August 2026 veröffentlichten Forscher von Mysk eine Analyse von drei WebKit-Mechanismen, die den Datenverkehr um einen konfigurierten Proxy herum leiten – direkt vom Gerät. Betroffen sind alle iOS-Browser mit Proxy-Modus, einschließlich Tor-Browser, sowie Apples eigener Dienst – iCloud Private Relay. Der Proxy ist aktiviert, die Benutzeroberfläche zeigt ein fremdes Land an, während die Website Ihre echte IP-Adresse und Ihren heimischen DNS-Resolver sieht.
Dies ist keine exotische Schwachstelle für Paranoiker. Es ist eine anschauliche Demonstration einer architektonischen Regel, die jeder, der über einen Proxy arbeitet, verinnerlichen sollte: Ein Proxy auf Anwendungsebene schützt nur den Datenverkehr, der durch den Netzwerk-Stack dieser Anwendung fließt. Alles, was vom Betriebssystem oder einem einzelnen Systemdienst erzeugt wird, geht vorbei.
Was genau fließt
Die Untersuchung begann mit einer alltäglichen Situation: Ein Benutzer des Proxy-Browsers Psylo beschwerte sich beim Entwickler über einen DNS-Leck. Die Analyse der Beschwerde offenbarte drei unabhängige Leckkanäle – alle liegen im WebKit selbst und nicht in einer bestimmten Anwendung.
1. DNS-Prefetching – der einfachste und unangenehmste
Mechanismus: Das Tag <link rel="dns-prefetch"> fordert den Browser auf, den Hostnamen im Voraus aufzulösen, um zukünftige Ladezeiten zu beschleunigen. Das Problem ist, dass WebKit auf iOS solche Namen über den normalen DNS-Pfad des Geräts auflöst und nicht über den Proxy.
Der Desktop-Safari-Browser unterstützt DNS-Prefetch seit Safari 5, aber iOS ignorierte dieses Tag – bis iOS 26.0 (September 2025). Damals aktivierte WebKit es im Rahmen derselben Änderung, die das alte implizite spekulative DNS-Prefetching entfernte (Bug 285744).
Wie es ausgenutzt wird: Eine Seite bettet in solche Tags einzigartige Hostnamen für jeden Besucher ein und beobachtet dann einfach, wie die Anfragen an ihren eigenen autoritativen DNS-Server kommen – von der echten IP-Adresse des Besuchers. Kein JavaScript, keine Benutzerinteraktion. Es reicht aus, die Seite zu öffnen.
2. WebAuthn Related Origin Requests – Leck durch Passkey
Dieser Kanal entstand bereits in iOS 18.0. Wenn eine Website nach WebAuthn-Anmeldeinformationen (d.h. Passkey) fragt, überprüft das System die Datei https://<rpId>/.well-known/webauthn – um sicherzustellen, dass die Domain tatsächlich mit der angegebenen relying party verbunden ist.
Ein entscheidendes Detail: Diese Überprüfungsanfrage stammt nicht aus dem Netzwerk-Stack des Browsers. Sie wird von dem Anmeldeinformationsdienst des Betriebssystems ausgeführt, der selbst HTTPS-Anfragen direkt vom Gerät sendet. Der im Browser konfigurierte Proxy weiß einfach nichts davon (Bug 268426).
Das heißt, es reicht aus, wenn die Seite eine Passkey-Anfrage initiiert – und der Server des Angreifers erhält eine Verbindung von Ihrer echten IP.
3. WebTransport – QUIC direkt vom Gerät
Der neueste Kanal. Der Aufruf new WebTransport(url) öffnet eine QUIC-Verbindung direkt vom Gerät, umgeht die Proxy-Konfiguration. WebTransport war in WebKit lange deaktiviert und wurde im März 2026 öffentlich in iOS 26.4 aktiviert (Bugs 260810 und 303453).
Wer ist betroffen
Apple verlangt, dass alle Browser auf dem iPhone WebKit verwenden. Folglich ist jeder iOS-Browser betroffen, der auf die WebKit-Proxy-API angewiesen ist – einschließlich aller iOS-Versionen von Tor-Browsern und dem Psylo, von dem die Untersuchung ausging. Dazu kommen Safari und iCloud Private Relay.
Was nicht betroffen ist – VPN-Anwendungen. Diese arbeiten auf Systemebene und leiten den gesamten Datenverkehr des Geräts, einschließlich des von Systemdiensten erzeugten. Das ist der entscheidende Unterschied: Ein Systemtunnel hat kein „vorbei“. Eine Ausnahme ist der Onion Browser auf Sicherheitsniveau Silver mit aktiviertem Lockdown-Modus: Er ist unempfindlich gegenüber Lecks durch WebTransport.
Von Seiten der Entwickler gibt es bereits eine Reaktion. In Psylo 1.3.1 wurden alle drei Kanäle geschlossen: Die Anwendung blockiert die Hinweise auf DNS-Prefetch (die Seite kann das Gerät nicht mehr dazu bringen, von Angreifern kontrollierte Namen aufzulösen), und WebTransport sowie WebAuthn sind standardmäßig deaktiviert – sie können gezielt über separate Schalter aktiviert werden. Apple plant laut Stand der Veröffentlichung, die Probleme in einem zukünftigen Update zu beheben; konkrete Fristen wurden vom Unternehmen nicht genannt.
Warum ist das erst jetzt aufgekommen
Die Chronologie ist hier aufschlussreich und sollte separat betrachtet werden – sie erklärt, warum das Problem früher nicht bemerkt wurde.
- September 2024, iOS 18.0 – Der Mechanismus der WebAuthn Related Origin Requests wird eingeführt. Der Leckkanal existiert seit fast zwei Jahren und wird in dieser Zeit von niemandem diskutiert: Die Überprüfung der Domain für Passkeys sieht aus wie ein Sicherheitsmerkmal und nicht wie ein Weg, die Adresse offenzulegen.
- September 2025, iOS 26.0 – WebKit aktiviert die Unterstützung für DNS-Prefetch auf mobilen Geräten. Formal ist dies eine Geschwindigkeitsoptimierung; tatsächlich erhält die Seite die Möglichkeit, das Gerät dazu zu bringen, auf einen beliebigen DNS-Namen um den Proxy herum zuzugreifen.
- März 2026, iOS 26.4 – WebTransport wird öffentlich aktiviert. Der dritte Kanal.
- August 2026 – Die Beschwerde eines Benutzers über ein DNS-Leck führt zu einer Untersuchung, die alle drei Kanäle gleichzeitig aufdeckt.
Der gemeinsame Nenner: Keine dieser Funktionen wurde als Kanal zur De-Anonymisierung gedacht. Alle drei sind gewöhnliche Funktionen der Plattform: Beschleunigung der Auflösung, Überprüfung von Passkeys, moderner Transport. Sie werden nur in Kombination mit dem Proxy-Modus auf Anwendungsebene zu Lecks, und genau deshalb wurden sie jahrelang nicht in dieser Hinsicht überprüft.
Die praktische Schlussfolgerung ist einfach und unangenehm: Das Fehlen von Nachrichten über Lecks bedeutet nicht, dass sie nicht existieren. Man muss selbst regelmäßig überprüfen und nicht darauf warten, dass jemand eine Analyse veröffentlicht.
Wie man sich selbst überprüfen kann
Die Forscher haben eine öffentliche Testumgebung bereitgestellt – leaks.psylo.app. Sie überprüft drei Dinge: normalen HTTPS-Datenverkehr (welche IP und welche DNS-Resolver der Server sieht), WebTransport und die Kombination von WebAuthn + DNS-Prefetch. Öffnen Sie sie mit aktiviertem Proxy und vergleichen Sie das Ergebnis mit der Adresse, die Sie erwarten zu sehen.
Es ist auch wichtig, die grundlegende Hygiene zu überprüfen – ob IP, DNS und WebRTC-Adresse in Ihrem Arbeitsbündel übereinstimmen. Wenn Sie sich zuvor nicht systematisch damit beschäftigt haben, beginnen Sie mit unserer Analyse: wie man einen Proxy auf DNS-Lecks überprüft.
Praktische Schlussfolgerung: Die Schicht zählt
Die Geschichte mit WebKit ist ein spezieller Fall einer allgemeinen Regel, die man im Hinterkopf behalten sollte, wenn man über einen Proxy arbeitet, auf jeder Plattform.
- Proxy im Browser ≠ Proxy auf dem Gerät. Die Konfiguration innerhalb der Anwendung deckt genau den Datenverkehr ab, den die Anwendung selbst sendet. Systemdienste, Hintergrundprozesse, Updates, Push-Verbindungen und, wie sich herausstellte, der integrierte Passkey-Dienst – all das geht seinen eigenen Weg.
- Lecks treten nicht nur an „bekannten“ Stellen auf. WebRTC ist seit langem im Gespräch, und man hat gelernt, es zu stopfen. DNS-Prefetching und die Überprüfung von WebAuthn sind Funktionen der Leistung und Sicherheit, die niemand als Kanal zur De-Anonymisierung betrachtet hat. Neue Funktionen der Browser schaffen regelmäßig neue Umgehungsmöglichkeiten.
- Ein Update der Plattform kann Ihre Sicherheit stillschweigend brechen. Hier ist es buchstäblich an den Daten zu sehen: DNS-Prefetching wurde in iOS 26.0 „aktiviert“, WebTransport in iOS 26.4. Der Benutzer hat nichts geändert, und die Oberfläche des Lecks ist gewachsen.
Was bedeutet das für Multi-Accounting und Automatisierung
Für diejenigen, die mehrere Konten führen oder Daten sammeln, ist das Risiko hier nicht abstrakt-privat, sondern durchaus finanziell. Antifraud-Systeme der Plattformen vergleichen Signale: Wenn eine Sitzung eine IP angibt, und die begleitende Anfrage von einer anderen Adresse und einem heimischen Resolver kommt, ist das ein guter Grund, die Konten miteinander zu verknüpfen oder die Sitzung als verdächtig zu kennzeichnen.
Praktische Folgerungen:
- Führen Sie keine Arbeits-Multi-Account-Sitzungen in mobilen Browsern mit Proxy-Modus. Solange die Plattform die Löcher nicht geschlossen hat, ist die Anwendungsschicht auf iOS definitionsgemäß unzuverlässig.
- Leiten Sie den Datenverkehr systematisch um. Wenn die Aufgabe ein mobiles Umfeld ist, ist es sinnvoller, den Proxy auf Geräteebene zu aktivieren oder über ein separates Gateway zu routen, anstatt sich auf die Konfiguration innerhalb des Browsers zu verlassen.
- Überprüfen Sie die Verbindung nach jedem größeren Update des Betriebssystems und des Browsers. Mindestens einmal im Quartal. Machen Sie dies zu einem Punkt auf Ihrer Checkliste, und warten Sie nicht, bis „etwas schiefgeht“.
- Deaktivieren Sie, was Sie nicht verwenden. WebTransport und WebAuthn sind in einem Arbeitsprofil für Parsing oder SMM fast sicher nicht nötig – ihre Deaktivierung entfernt zwei von drei Leckkanälen.
Die Qualität der IP bleibt dabei eine separate Variable: Selbst bei einer hermetischen Konfiguration gibt der Rechenzentrumsadresse sich durch ASN zu erkennen. Für Szenarien, in denen es wichtig ist, wie ein normaler Benutzer auszusehen, funktionieren residential proxies, und für mobile Anwendungen und Plattformen mit den strengsten Antifraud-Maßnahmen – mobile proxies mit IPs echter Mobilfunkanbieter. Aber keine Proxy-Klasse wird helfen, wenn ein Teil des Datenverkehrs physisch daran vorbeigeht – zuerst die Hermetik, dann die Qualität der Adresse.
Fazit
Drei Bugs in WebKit – DNS-Prefetching, WebAuthn Related Origin Requests und WebTransport – haben gezeigt, dass „Proxy aktiviert“ und „der gesamte Datenverkehr geht über den Proxy“ zwei verschiedene Aussagen sind. Auf iOS war die Kluft zwischen ihnen groß genug, damit eine gewöhnliche Webseite ohne eine einzige Zeile JavaScript die echte Adresse eines Besuchers des Tor-Browsers erfahren konnte.
Während Apple an einer Lösung arbeitet, ist die einzige praktikable Strategie, zu überprüfen und nicht zu vermuten. Öffnen Sie die Testumgebung, vergleichen Sie die Adressen, deaktivieren Sie überflüssige APIs. Und betrachten Sie jedes größere Update des Betriebssystems als ein Ereignis, nach dem die Konfiguration erneut überprüft werden muss. Der Unterschied zwischen Privatsphäre und deren Illusion besteht oft genau in einer nicht rechtzeitig gestellten Frage: „Ist wirklich der gesamte Datenverkehr?“ Es ist auch nützlich zu verstehen, welche anderen Signale Sie neben der Adresse preisgeben – darüber haben wir in unserem Artikel über Schutz vor Browser-Fingerprinting geschrieben.