Tech

Fuite IP et DNS de WebKit : comment elle expose les utilisateurs d'iCloud Private Relay

Hacker Newsil y a 2 h
Écran de smartphone avec une icône de cadenas
Écran de smartphone avec une icône de cadenasPhoto: Brett Jordan / Pexels

Un nouveau rapport publié sur le blog de recherche en sécurité Mysk décrit une faille de fuite d'IP et de DNS enracinée dans WebKit, le moteur de navigateur qui fait fonctionner Safari et, selon les règles de l'App Store d'Apple, toute autre application de navigateur sur iPhone et iPad — y compris les navigateurs proxy tiers que les utilisateurs emploient spécifiquement pour masquer leur localisation et leur activité réseau. Cette découverte est significative car elle sape la protection de la vie privée même que ces outils promettent, révélant l'adresse IP réelle d'un utilisateur ou ses requêtes DNS à un site web ou à un observateur réseau, même lorsqu'un tunnel proxy ou de type VPN est actif.

WebKit est le moteur de navigateur d'Apple, et parce qu'Apple exige que chaque navigateur iOS — qu'il s'agisse de Safari, de Chrome pour iOS ou d'un navigateur proxy dédié à la confidentialité — restitue les pages via WebKit plutôt que via son propre moteur, toute fuite au sein de WebKit lui-même affecte potentiellement chaque navigateur de la plateforme, pas seulement Safari. Ce point de défaillance unique rend cette catégorie de bug plus lourde de conséquences sur iOS qu'une faille comparable ne le serait sur ordinateur, où les navigateurs embarquent leurs propres moteurs indépendants.

La fuite décrite par le rapport porte notamment sur la façon dont certaines requêtes réseau — en particulier celles liées à la résolution DNS et à des API WebKit spécifiques — peuvent contourner le tunnel mis en place par un navigateur proxy ou par le Relais privé iCloud d'Apple lui-même. Le Relais privé est conçu pour acheminer le trafic web d'un utilisateur via deux relais distincts, de sorte que ni le fournisseur réseau ni le site de destination ne peuvent voir à la fois l'identité de l'utilisateur et le site visité.

Lorsqu'une fuite DNS ou IP se produit, cette séparation s'effondre. Un site web ou un réseau positionné entre l'utilisateur et internet peut potentiellement voir l'adresse IP réelle de l'utilisateur, ou observer quels domaines l'appareil résout, alors même que l'utilisateur croit son trafic anonymisé derrière le relais ou le tunnel proxy. Pour quelqu'un utilisant ces outils précisément pour éviter d'être suivi ou géolocalisé, c'est exactement le mode de défaillance qu'il tentait d'empêcher.

Ce type de fuite n'est pas propre à WebKit dans l'histoire des outils de confidentialité des navigateurs ; les fuites d'IP basées sur WebRTC et les fuites liées au préchargement DNS ont affecté pendant des années les configurations VPN et proxy sur d'autres moteurs de navigateur, souvent parce qu'une fonctionnalité conçue pour la performance — résoudre un nom de domaine tôt, ou établir une connexion pair à pair avant qu'elle ne soit nécessaire — n'avait jamais été auditée pour son comportement lorsque le navigateur est censé tout tunneliser via un point de sortie distinct.

Ce qui rend les navigateurs proxy sur iOS particulièrement exposés, c'est qu'ils ne peuvent généralement pas remplacer WebKit par leur propre pile réseau comme le ferait un navigateur de bureau embarquant son propre résolveur DNS. Ils se limitent en grande partie à configurer ce que WebKit reçoit, ce qui signifie qu'une fuite dans la logique même de traitement des requêtes de WebKit est très difficile à contourner pour un navigateur proxy tiers, et nécessite en pratique un correctif d'Apple.

Pour les utilisateurs du Relais privé iCloud, l'exposition est plus étroite mais tout aussi notable, car le Relais privé est censé être la garantie propriétaire d'Apple pour exactement ce type de protection. Une fuite permettant à un site de destination de voir l'adresse IP réelle derrière le Relais privé sape la fonctionnalité spécifique que Apple commercialise comme une amélioration de la confidentialité pour les abonnés iCloud+, plutôt qu'un contournement bricolé par un développeur tiers.

Les chercheurs en sécurité qui étudient cette catégorie de bug recommandent généralement une réponse par couches plutôt que de s'appuyer sur un seul outil : associer un proxy ou un relais à un fournisseur DNS configuré pour bloquer les fuites, tester les fuites avec des outils dédiés basés sur le navigateur avant de faire confiance à une configuration, et considérer la garantie de tout outil de confidentialité comme provisoire jusqu'à ce que des chercheurs indépendants aient essayé de la briser dans des conditions réseau réelles.

Pour les utilisateurs ordinaires qui ne sont pas des chercheurs en confidentialité, la leçon pratique est plus modeste : les navigateurs proxy et le Relais privé relèvent nettement la barre contre le suivi occasionnel, mais ils ne constituent pas une garantie absolue contre un observateur réseau ou un site web suffisamment déterminé, et les utilisateurs ayant des besoins d'anonymat aigus — journalistes, militants, personnes fuyant une surveillance — devraient traiter tout outil au niveau du navigateur comme une couche parmi d'autres dans une défense plus large, et non comme la défense entière.

Apple a l'habitude de corriger les problèmes de WebKit une fois signalés de manière responsable, et le schéma habituel pour une fuite de ce type est un correctif livré dans une mise à jour ultérieure d'iOS et de Safari plutôt qu'une reconnaissance publique du mécanisme sous-jacent. En attendant qu'un tel correctif arrive, le message central du rapport rappelle que « privé » et « chiffré » ne sont pas automatiquement synonymes d'« étanche aux fuites », même pour des outils conçus spécifiquement pour empêcher ce genre précis d'exposition.

Cet article est un résumé éditorial assisté par IA basé sur Hacker News. L'image est une photo d'archive de Brett Jordan sur Pexels.

À lire ensuite

Baies de serveurs d'un data center de nuit
Plus dans Tech

Pourquoi le Texas suspend-il les nouveaux raccordements des data centers au réseau ?

Selon Ars Technica, le Texas a suspendu les nouveaux raccordements à grande échelle de data centers à son réseau électrique géré par ERCOT, après qu'une vague de demandes de raccordement liées à l'IA a menacé de dépasser la capacité du réseau. Cette décision est notable car le gouverneur de l'État a passé les deux dernières années à présenter le Texas comme un « épicentre » de l'infrastructure IA. Des files d'attente de raccordement tout aussi tendues sont aussi apparues en Virginie et dans la région de PJM Interconnection, à mesure que les data centers d'IA deviennent plus gourmands en électricité.

Ars Technica
Fusée sur son pas de tir
Tech

SpaceX double ses revenus grâce aux contrats de calcul IA avec Anthropic et Google

Le chiffre d'affaires de SpaceX a à peu près doublé en glissement annuel lors de son premier rapport de résultats trimestriels en tant qu'entreprise cotée, porté par de nouveaux contrats de calcul IA avec Anthropic et Google ainsi que par la croissance continue de Starlink. L'activité de calcul a triplé pour atteindre environ 2,6 milliards de dollars, mais la division IA a tout de même affiché une perte trimestrielle de 1,5 milliard de dollars. Ces résultats placent SpaceX en concurrence directe avec des fournisseurs « neocloud » dédiés comme CoreWeave sur le marché de l'infrastructure IA.

TechCrunchil y a 2 h
Écran de smartphone avec une épingle de localisation sur une carte
Tech

Comment les SDK tiers des applications Android divulguent votre position aux annonceurs

Une nouvelle enquête de l'Electronic Frontier Foundation, relayée par TechCrunch, révèle que les SDK publicitaires et analytiques tiers intégrés dans de nombreuses applications Android peuvent collecter et partager les données de localisation des utilisateurs même lorsque les développeurs de l'application ne l'avaient jamais prévu. Comme Android accorde l'autorisation de localisation au niveau de l'application, chaque SDK intégré hérite du même accès approuvé par l'utilisateur pour l'application entière. L'EFF appelle les développeurs à auditer leurs SDK et les utilisateurs à revoir les autorisations de localisation application par application.

TechCrunchil y a 2 h
Concentrateur domotique et appareils connectés
Tech

Zigbee contre Matter sur Thread : quel protocole domotique est le plus performant ?

Zigbee et Matter sur Thread sont les deux protocoles principaux qui rivalisent pour faire fonctionner les réseaux domotiques, et une nouvelle comparaison publiée sur arXiv teste lequel des deux performe réellement mieux en pratique. L'étude montre que Zigbee garde un avantage en latence brute et en autonomie des piles dans les déploiements maillés denses, tandis que Matter sur Thread sacrifie une partie de son efficacité pour l'interopérabilité entre marques. Le protocole gagnant dépend de si un foyer démarre de zéro ou a déjà investi dans un écosystème.

Hacker Newsil y a 2 h