Fuite IP et DNS dans WebKit : iCloud Private Relay pris en défaut

Apple vend iCloud Private Relay comme une protection de la vie privée digne de confiance : ton IP réelle ne devrait jamais atteindre les sites que tu visites, tes requêtes DNS ne partent pas en clair vers ton FAI ou ton opérateur mobile. Sur le papier, l’architecture est élégante. En pratique, une publication récente de l’équipe Mysk révèle que WebKit — le moteur de rendu derrière Safari et tous les navigateurs iOS sans exception — peut laisser fuiter ton adresse IP et tes requêtes DNS malgré le relais actif. Ambiance.

Ce n’est pas un bug de niche. Sur iOS, Apple impose à tous les navigateurs tiers — Chrome, Firefox, Brave, Opera, peu importe — d’utiliser WebKit sous le capot. La vulnérabilité ne touche donc pas que Safari : elle concerne potentiellement n’importe quelle application de navigation sur iPhone ou iPad. Y compris les « proxy browsers » qui promettent précisément de masquer ton identité en ligne.

Le timing est piquant : iCloud Private Relay était justement présenté comme une réponse aux limites des VPN classiques, une protection intégrée au système. Un utilisateur qui l’active pense légitimement être à l’abri. Il a tort, au moins partiellement — et ça mérite qu’on creuse pourquoi.

iCloud Private Relay : deux sauts, un angle mort

Pour comprendre la faille, il faut comprendre comment Private Relay est censé fonctionner. Disponible depuis iOS 15 avec un abonnement iCloud+, le service repose sur un modèle à deux relais inspiré des principes du routage en oignon. L’idée : aucun acteur unique ne peut voir simultanément ton IP et ta destination.

Premier saut : ton trafic arrive chiffré sur un serveur Apple (l’ »ingress proxy »). Apple connaît ton IP réelle mais ne peut pas lire la destination — elle est chiffrée. Apple transmet ensuite le paquet à un serveur secondaire géré par un prestataire tiers (Cloudflare ou Fastly selon les régions), en remplaçant ton IP par une adresse anonymisée. Deuxième saut : ce serveur tiers (l’ »egress proxy ») déchiffre la destination finale et effectue la requête. Il voit où tu vas, mais ne voit que l’IP anonymisée, jamais la tienne.

L’architecture est théoriquement solide. Mais elle repose sur une hypothèse critique : que tout le trafic réseau de l’appareil passe effectivement par ces deux relais. Si une partie du trafic s’échappe en dehors du tunnel — pour des connexions multimédia, des résolutions DNS ou d’autres requêtes de bas niveau — la protection s’effondre partiellement. C’est exactement ce que Mysk a documenté et reproduit.

Ce que WebKit fait dans ton dos

Le cœur du problème : WebKit effectue certaines résolutions DNS et connexions réseau directement, en dehors du tunnel Private Relay. Les chercheurs de Mysk ont identifié que le chargement de ressources multimédias — des flux vidéo ou audio déclenchés via certaines APIs HTML5 — peut initier des connexions réseau avant que le proxy ait pu les intercepter et les faire transiter par le relais.

Concrètement : lorsqu’une page web charge un élément multimédia pointant vers un serveur distant, WebKit peut résoudre le DNS et établir la connexion TCP/IP directement depuis l’interface réseau de l’appareil. Le serveur distant voit alors l’IP réelle de l’utilisateur dans ses logs, pas l’IP anonymisée du relais. Pour la fuite DNS, c’est encore plus simple — la requête sort en clair sur le réseau local, visible par ton FAI ou ton opérateur mobile, même sans aucun serveur malveillant à l’autre bout.

Le proxy intercepte les requêtes HTTP. Le moteur de rendu, lui, peut contourner le proxy sans te demander la permission — et sans t’en informer.

Ce vecteur n’est pas nouveau en soi : les fuites via WebRTC ont longtemps été le cauchemar des utilisateurs de VPN sur desktop. Mais ici, le problème vient du moteur de rendu lui-même, pas d’une API optionnelle que l’on peut désactiver. Et sur iOS, tu n’as pas le choix du moteur.

Proxy browsers : le faux sentiment de protection

Les proxy browsers — navigateurs qui acheminent tout leur trafic via un serveur proxy avant de renvoyer le contenu — ont explosé en popularité ces dernières années. La promesse est claire : connexion anonymisée, contournement des restrictions géographiques, protection contre le pistage. Des apps comme Onion Browser ou certains navigateurs avec VPN intégré utilisent ce modèle.

Mais sur iOS, ces navigateurs tournent sur WebKit et héritent mécaniquement du problème. Le proxy intercepte correctement les requêtes HTTP et HTTPS générées par l’application. Les connexions réseau initiées directement par le moteur WebKit pour charger des ressources multimédias, elles, peuvent passer entre les mailles. Pour des utilisateurs qui comptent sur ces outils dans des contextes sensibles — journalistes, militants, personnes dans des pays à censure active — cette limitation n’est pas un détail technique. Elle peut avoir des conséquences concrètes sur leur sécurité opérationnelle. Et surtout, elle est invisible : aucune alerte ne signale que certaines connexions fuient hors du tunnel.

Comment Mysk a mis la fuite en évidence

La méthodologie est documentée et reproductible. Les chercheurs ont configuré un serveur de test contrôlé loggant toutes les connexions entrantes et requêtes DNS, puis chargé depuis un iPhone (avec Private Relay activé) une page contenant des ressources multimédias pointant vers ce serveur. Résultat : des connexions directes apparaissent dans les logs avec l’IP réelle de l’appareil — pas celle du relais. La fuite DNS est capturée de la même façon, visible en clair via un simple monitoring réseau avec Wireshark ou Little Snitch côté macOS.

Le rapport a été publié le 4 août 2026. À l’heure où j’écris, Apple n’a pas communiqué de calendrier de correctif. La vulnérabilité a vraisemblablement été remontée en amont de la publication selon les pratiques de divulgation responsable, mais les délais de patch sur WebKit peuvent s’étirer sur plusieurs semaines. En attendant, le bug est documenté, reproductible, et public.

Ce que tu peux faire concrètement en attendant

La mauvaise nouvelle d’abord : tant qu’Apple n’a pas corrigé WebKit, il n’existe pas de solution parfaite sur iOS. Tu ne peux pas remplacer le moteur de rendu. Tu ne peux pas désactiver sélectivement les connexions réseau initiées par WebKit sans casser l’affichage des pages web.

Les mesures palliatives disponibles : privilégier un VPN au niveau système plutôt qu’un proxy applicatif. Un VPN système configuré via les profils iOS (WireGuard, par exemple) intercepte théoriquement tout le trafic réseau avant qu’il ne sorte de l’appareil — y compris les connexions initiées directement par WebKit. C’est une protection plus robuste qu’un proxy applicatif, même si aucune solution n’est absolument garantie selon la configuration. Sur macOS, en revanche, Chrome utilise Blink et Firefox utilise Gecko : ces navigateurs ne sont pas affectés par ce bug spécifique, ce qui change significativement l’analyse de risque.

Si tu gères des infrastructures web ou des hébergements, tu peux aussi analyser tes logs d’accès côté serveur : des connexions qui prétendent venir via Private Relay mais qui montrent des patterns IP incohérents peuvent signaler des clients affectés. Ce n’est pas une protection pour l’utilisateur final, mais ça peut informer une politique de sécurité côté back-end.

Le vrai problème, c’est le monopole WebKit sur iOS

Ce bug illustre une contradiction structurelle dans la stratégie Apple. D’un côté, la marque se positionne activement sur la vie privée depuis des années — App Tracking Transparency, Private Relay, Hide My Email, le discours « Privacy is a human right ». De l’autre, la règle qui impose WebKit à tous les navigateurs iOS crée un point de défaillance unique : si WebKit a un problème de confidentialité, tout l’écosystème en souffre simultanément. Pas de diversité, pas de résilience.

L’Union européenne a commencé à corriger ça via le Digital Markets Act, qui oblige Apple à permettre d’autres moteurs de rendu sur iOS dans l’espace européen. En pratique, l’adoption reste timide. Mais ce bug est exactement l’argument qui justifie cette ouverture : la diversité des moteurs répartit les risques. Si Chrome sur iOS pouvait utiliser Blink, cette faille WebKit ne l’affecterait pas.

Mon avis, sans détour : iCloud Private Relay est un produit avec une architecture solide en théorie, mais vendu avec un niveau de confiance que son implémentation actuelle ne justifie pas. Une protection de la vie privée qui fuit silencieusement est plus dangereuse qu’une absence de protection — parce qu’elle installe un faux sentiment de sécurité. Si tu as des besoins réels de confidentialité en ligne, un VPN audité et un navigateur sur moteur non-WebKit (sur macOS ou Android) restent des choix plus fiables aujourd’hui. Et si tu construis une application qui manipule des données sensibles côté client, intègre cette réalité dans ton modèle de menace : le navigateur de l’utilisateur n’est pas nécessairement l’environnement de confiance que tu crois.