Zusammenfassung

  • Die Forscher Talal Haj Bakry und Tommy Mysk dokumentierten drei WebKit-Pfade, die einen Proxy auf Anwendungsebene umgehen können: DNS-Prefetch, WebAuthn Related Origin Requests und WebTransport.
  • DNS-Prefetch kann den gewöhnlichen DNS-Resolver des Geräts offenlegen; WebAuthn und WebTransport können einer vom Anbieter kontrollierten Gegenstelle die reale IP-Adresse zeigen.
  • Mysk datiert die betreffenden Mechanismen auf iOS 18.0 für Related Origin Requests, iOS 26.0 für DNS-Prefetch und iOS 26.4 für WebTransport.
  • TechCrunch testete den veröffentlichten Nachweis am 5. August selbst und sah die eigene reale Adresse, obwohl Private Relay aktiviert war.
  • Apple beschreibt Private Relay als Zwei-Hop-Schutz für Safari-Verkehr, DNS-Anfragen und einen Teil unverschlüsselten HTTP-Verkehrs, nicht als systemweites VPN.
  • Psylo 1.3.1 begrenzt die drei Pfade lokal; zum Stichtag gab es jedoch weder eine bestätigte Apple-Reaktion noch CVE, Plattform-Patch oder belastbare Verbreitungsmessung.

Eine Seite, drei Netzverantwortliche

Für den Nutzer gehören alle Verbindungen zur geöffneten Webseite. Technisch verteilt WebKit sie jedoch auf verschiedene Eigentümer. Safari steuert den gewöhnlichen Seitenabruf, ein Betriebssystemdienst prüft die Beziehung zwischen WebAuthn-Domains, und WebTransport eröffnet eine eigene HTTP/3- und QUIC-Verbindung. Nur weil die Seite den Vorgang ausgelöst hat, übernimmt der jeweilige Dienst nicht automatisch die Proxykonfiguration des Browsers.

Damit ist der Befund kein Nachweis gebrochener Relay-Kryptografie. Apples Trennung kann für jede Verbindung funktionieren, die tatsächlich in den Zwei-Hop-Pfad gelangt. Das Leck entsteht vorher: Ein Unterauftrag verlässt den geschützten Kontext, weil die Richtlinie an einer Komponenten- und API-Grenze nicht weitergereicht wird. Ein isoliert korrektes Browser-, Anmelde- und Transportmodul ergibt zusammen noch keine vollständige Datenschutzgrenze.

DNS-Prefetch verrät einen Resolverpfad, nicht zwingend dieselbe Adresse

Mit dns-prefetch kann eine Seite einen Hostnamen auflösen lassen, bevor sie ihn benötigt. Nach Mysks Tests sendet WebKit diese Abfrage über den normalen DNS-Weg des Geräts statt über den Anwendungsproxy. Gibt eine Seite jedem Besuch einen einzigartigen Namen, kann ihr autoritativer DNS-Server erkennen, welcher reale Resolver und Netzkontext die Anfrage liefert.

Das ist nicht automatisch gleichbedeutend mit der exakten öffentlichen IP-Adresse, die ein Webserver bei einer Direktverbindung sieht. Caches, Resolverarchitektur und Netzkonfiguration beeinflussen die Beobachtung. Die Abweichung bleibt relevant, weil Apple DNS-Auflösung ausdrücklich zum Schutzumfang zählt. Eine seriöse Risikobewertung muss deshalb Resolveroffenlegung und zielseitige IP-Offenlegung getrennt bilanzieren.

Die WebAuthn-Prüfung kann vor einer sichtbaren Anmeldung laufen

WebAuthn Related Origin Requests erlauben einer Organisation, Zugangsdaten über kontrollierte Domains hinweg einzusetzen. Bevor das System eine abweichende Relying-Party-ID akzeptiert, ruft sein Anmeldedienst eine Validierungsdatei von der zugehörigen Domain ab. Die Forscher berichten, dass dieser Abruf nicht den von Safari verwendeten Proxyweg nimmt. Die Gegenstelle kann dadurch die Geräteadresse sehen.

Entscheidend ist, dass der Nutzer keinen Passkey auswählen oder eine Anmeldung abschließen muss. Bei conditional mediation lässt sich die Validierung ohne sichtbare Aufforderung anstoßen. Die Schwäche als „IP-Leck bei der Passkey-Nutzung“ zu beschreiben, wäre daher zu eng. Das Kontrollproblem liegt in der Fähigkeit einer Seite, einen direkten Systemabruf zu veranlassen, bevor eine bewusste Authentifizierungsentscheidung fällt.

WebTransport eröffnet eine parallele Datenebene

WebTransport stellt latenzarme Streams und Datagramme über HTTP/3 und QUIC bereit. Laut Mysk baut WebKit diese Verbindung auf, ohne die Proxykonfiguration der Browsersitzung mitzunehmen. Der Server erhält dann eine direkte Verbindung vom Gerät statt von einer Relay-Adresse. Anders als beim DNS-Pfad handelt es sich um eine für das Ziel sichtbare reale IP-Adresse.

Die Technik ist für interaktive Anwendungen legitim und nützlich. Ein dauerhafter Fix kann daher nicht darin bestehen, jede direkte Transportfunktion pauschal zu verbieten. Die Plattform braucht eine einheitliche Regel: Entsteht eine Nebenverbindung aus einem geschützten Browserkontext, muss sie dessen Route erben, blockiert werden oder eine verständliche Ausnahme verlangen. Ohne diese Regel wird jede neue Netzwerk-API zu einer erneuten Grenzprüfung.

Apples dokumentierter Umfang setzt die richtige Messlatte

Apple sagt, Private Relay schütze Safari-Browsing, DNS-Auflösung und unverschlüsselten HTTP-Verkehr bestimmter Apps. Der Dienst ersetzt die Quelladresse durch eine Relay-Adresse und erhält nur einen groben Standort. Er ist bewusst kein VPN, das den gesamten Systemverkehr tunnelt. Auch die Forscher sagen, dass VPNs von den drei konkreten Pfaden nicht in gleicher Weise betroffen seien.

Diese Abgrenzung verhindert Übertreibung in beide Richtungen. Eine Schutzanzeige in Safari verspricht nicht, dass jedes Paket des Geräts durch das Relay läuft. Die Demonstration beweist aber ebenso wenig, dass sämtlicher Private-Relay-Verkehr offenliegt. Belegt sind drei konkrete Nebenwege und ein unabhängiger Test von TechCrunch. Nicht belegt sind die Häufigkeit auf realen Geräten, eine Nutzung durch Websites vor der Veröffentlichung oder eine universelle Betroffenheit jeder Konfiguration.

Browsermaßnahmen gewinnen Zeit, die Plattform muss die Grenze schließen

Psylo 1.3.1 blockiert DNS-Prefetch und deaktiviert WebTransport sowie WebAuthn standardmäßig; die beiden Funktionen lassen sich pro Silo freigeben. Die Forscher informierten außerdem Entwickler des Tor Project und von Onion Browser. Solche Maßnahmen verkleinern die Angriffsfläche eines einzelnen Browsers, kosten aber Kompatibilität und vereinheitlichen nicht die Richtlinien von WebKit, Anmeldedienst und Netzwerk-Framework.

Zum Stichtag lag keine von TechCrunch berichtete Stellungnahme Apples vor, ebenso kein CVE und kein bestätigter Plattform-Patch. Die Forscher hatten Apple nach eigener Aussage wegen früherer Erfahrungen nicht vorab informiert. Das ist weder Beleg für Anerkennung noch für Ablehnung. Entscheidend wird sein, ob Apple den Schutzkontext über spekulative DNS-Auflösung, Domainvalidierung und neue Transportsitzungen hinweg durchsetzen kann, statt jeden Browser zu separaten Funktionssperren zu zwingen.

Quellen