Fuites WebRTC, DNS et IPv6 : pourquoi une extension VPN ne ferme pas toute la surface d’exposition

Dossier technique

Une extension VPN peut modifier le chemin de sortie du navigateur sans pour autant neutraliser toutes les sources d’exposition réseau. Le problème ne se résume pas à “mon IP visible a-t-elle changé ?”. Il faut raisonner en couches : routage du navigateur, négociation WebRTC, résolution DNS, interfaces disponibles, IPv4/IPv6, paramètres de confidentialité du navigateur et flux qui continuent d’exister autour du simple proxying web.

Le raisonnement le plus trompeur consiste à réduire la confidentialité d’une extension VPN à un seul indicateur visible dans un onglet : l’adresse IP publique qu’un site affiche. Ce test apporte une information, mais il ne dit pas tout. Une extension peut influencer le trafic web qui passe par le navigateur sans prouver que la négociation WebRTC, la logique de résolution, l’exposition d’interfaces ou les autres comportements réseau du navigateur sont alignés sur la même politique.

C’est pour cette raison qu’un routage navigateur correct ne suffit pas à lui seul comme preuve de couverture. La bonne lecture n’est pas “le proxy fonctionne”, mais “quelles parties de la surface réseau du navigateur restent capables de révéler autre chose que le simple point de sortie HTTP/HTTPS visible”.

Une surface d’exposition n’est pas une simple adresse IP de sortie

Dans un navigateur, plusieurs mécanismes réseau coexistent. Le proxy navigateur n’est que l’un d’entre eux. Dès que l’on parle de WebRTC, de résolution préalable, de sélection d’interface ou de politiques de confidentialité propres au navigateur, on sort du réflexe simpliste qui consiste à résumer toute la question à “quelle IP voit le site”.

Une extension VPN peut donc être techniquement correcte sur sa couche propre tout en laissant subsister des angles morts. Cela ne signifie pas qu’elle est frauduleuse ou inutile. Cela signifie seulement qu’elle doit être évaluée comme un composant partiel, pas comme une preuve d’étanchéité globale.

Cette distinction prolonge directement le cadre posé dans Extension VPN vs application VPN et dans Proxy, PAC et routage navigateur.

WebRTC est une couche distincte, pas une anomalie marginale

WebRTC n’est pas un détail périphérique du navigateur. Son objectif est de permettre la communication temps réel entre pairs, avec une logique de connectivité qui ne se réduit pas à l’échange HTTP classique. Pour établir cette connectivité, le navigateur produit et échange des candidats ICE décrivant les protocoles et les chemins de routage utilisables.

Cette propriété suffit à expliquer pourquoi une extension VPN de type proxy ne règle pas automatiquement toute la question. Si le navigateur continue de négocier des chemins réseau dans un autre cadre fonctionnel, la simple modification du point de sortie web ne démontre pas que cette négociation est elle aussi strictement bornée.

Le problème n’est donc pas “WebRTC fuit par magie”. Le problème est plus sérieux : WebRTC obéit à sa propre logique de connectivité, et cette logique doit être gouvernée explicitement si l’on veut réduire la surface d’exposition.

ICE candidates : la négociation expose une réalité de routage

L’interface RTCIceCandidate représente une configuration ICE potentiellement utilisable pour établir une communication. MDN rappelle qu’un candidat ICE décrit les protocoles et le routage nécessaires pour qu’une connexion WebRTC puisse être négociée, et expose notamment une propriété address correspondant à l’adresse IP du candidat.

Ce point change la lecture du risque. Tant que l’on reste au niveau “le site voit telle IP”, on oublie que le navigateur peut manipuler et négocier des candidats décrivant autre chose que le seul chemin web visible. Une extension VPN peut donc afficher une apparence de protection homogène alors que la couche WebRTC continue d’introduire ses propres compromis de connectivité.

Il faut ici raisonner comme sur un vrai système : ce qui compte n’est pas seulement le flux principal, mais l’ensemble des mécanismes de négociation capables d’exposer des détails d’interface, de chemin ou d’adresse.

webRTCIPHandlingPolicy existe précisément parce que le sujet est réel

Chromium expose une politique dédiée à la gestion des IP WebRTC. Le fait même que cette politique existe est un signal fort : le navigateur distingue explicitement le routage WebRTC du simple routage proxy et propose des compromis entre performance média et confidentialité.

Côté Chromium, la valeur webRTCIPHandlingPolicy influence la façon dont le trafic WebRTC est routé et la quantité d’information d’adresse locale exposée. Côté documentation extension, le paramètre est manipulable via l’API privacy.network, à condition de déclarer la permission privacy.

{
  "manifest_version": 3,
  "permissions": ["privacy"]
}

chrome.privacy.network.webRTCIPHandlingPolicy.set({
  value: "disable_non_proxied_udp"
});

Le point à retenir n’est pas qu’il existerait un “mode magique” de non-fuite, mais qu’une extension sérieuse doit savoir si elle s’appuie ou non sur cette couche de contrôle, et comment elle la documente.

Les valeurs de la politique WebRTC décrivent des compromis, pas une sécurité absolue

Dans Chromium, plusieurs valeurs existent pour la gestion des IP WebRTC. Elles ne signifient pas la même chose. Certaines laissent un usage plus large des interfaces, d’autres le restreignent davantage. La lecture correcte n’est donc pas “WebRTC activé ou désactivé”, mais “quelle politique d’exposition et de routage est effectivement appliquée”.

• default : comportement par défaut du navigateur.
• default_public_and_private_interfaces : usage des interfaces publiques et privées.
• default_public_interface_only : restriction vers les interfaces publiques.
• disable_non_proxied_udp : limitation des usages UDP non proxifiés côté WebRTC.

Il faut être dur ici : voir une extension VPN “connectée” sans savoir quelle politique WebRTC est en place n’est pas un audit. C’est une impression de contrôle, pas une mesure du périmètre réel.

La résolution DNS n’est pas un simple détail de performance

Le navigateur ne se contente pas de charger des pages. Sa pile de confidentialité expose aussi des réglages comme networkPredictionEnabled, qui peuvent conduire à la pré-résolution DNS, au prérendu et à l’ouverture préventive de connexions TCP et TLS.

Ce point est important pour la lecture d’une extension VPN. Si le navigateur possède des comportements réseau propres autour de la résolution et de l’anticipation des connexions, alors un raisonnement centré exclusivement sur le proxy principal devient trop pauvre. Une extension peut contrôler un chemin de sortie tout en laissant exister d’autres comportements réseau du navigateur qui doivent être compris et, le cas échéant, bornés.

Ici encore, il ne s’agit pas de crier au “DNS leak” sans nuance. Il s’agit de rappeler que le navigateur a sa propre vie réseau, et qu’une extension VPN ne doit jamais être évaluée comme si cette vie se réduisait au seul flux de navigation principal.

IPv6 et sélection d’interface : l’exposition n’est pas seulement une affaire d’IPv4

Une lecture paresseuse des fuites se concentre souvent sur l’IPv4 visible. Or la documentation de la politique WebRTC parle explicitement des interfaces et de la quantité d’informations d’adresse locale exposées. Cela impose une lecture plus large : le problème n’est pas seulement “quelle IP publique sort”, mais aussi “quelles interfaces et quelles familles d’adresses le navigateur considère encore dans sa logique de connectivité”.

L’usage ou l’exposition d’IPv6 ne doit donc pas être réduit à une case à cocher. Si une extension VPN ne documente rien sur le traitement des interfaces, des politiques WebRTC ou de la connectivité non proxifiée, elle laisse une zone d’ombre. Ce n’est pas forcément une faute d’implémentation, mais c’est un défaut d’audit.

Désactiver RTCPeerConnection n’équivaut pas à une stratégie complète

Les APIs de confidentialité des extensions permettent aussi d’agir sur peerConnectionEnabled. C’est une option plus radicale, mais elle ne doit pas être surinterprétée. MDN précise que si cette valeur est mise à false, l’interface RTCPeerConnection est désactivée, mais que getUserMedia() n’est pas affecté.

Cette précision mérite d’être retenue : même une mesure plus agressive ne remplace pas une lecture globale des comportements réseau et média du navigateur. Une “protection” qui repose uniquement sur un interrupteur unique est rarement une analyse sérieuse.

Pourquoi une extension VPN ne ferme pas mécaniquement toute la surface d’exposition

La raison la plus importante est structurelle. Une extension VPN de navigateur agit sur une couche précise : permissions, politiques du navigateur, paramètres proxy, éventuellement paramètres de confidentialité exposés par l’API. Elle n’obtient pas, par nature, un contrôle universel sur tout ce que le navigateur et le poste peuvent révéler.

Dès lors, trois erreurs doivent être évitées :

• confondre changement d’IP visible avec couverture exhaustive ;
• ignorer la couche WebRTC et ses politiques propres ;
• oublier que le navigateur possède aussi des comportements réseau liés à la résolution et à la prédiction.

Une extension peut réduire une partie de l’exposition. Elle ne doit pas être présentée comme preuve automatique d’étanchéité.

Ce qu’il faut auditer concrètement

• La présence ou non d’un contrôle explicite de webRTCIPHandlingPolicy.
• Le niveau de politique réellement appliqué, et non l’interface marketing affichée.
• L’existence d’une documentation claire sur WebRTC, UDP non proxifié et interfaces réseau.
• Le rôle de networkPredictionEnabled dans la stratégie de confidentialité de l’extension.
• La cohérence entre la promesse “privacy” et la portée réelle du routage navigateur.
• L’absence ou non d’angles morts connus autour d’IPv6, des interfaces locales et des flux hors proxy.
• La différence entre contrôle apparent et contrôle effectif, surtout si d’autres extensions ou policies peuvent reprendre la main.

La suite logique est de rapprocher cette lecture de la méthode d’audit complète, ainsi que de la page sur les permissions et de la page sur Manifest V3 et les contraintes d’exécution.

Conclusion

Une extension VPN peut modifier utilement le routage du navigateur, mais elle ne ferme pas automatiquement toute la surface d’exposition réseau. WebRTC, la gestion des interfaces, les politiques IP, la résolution anticipée et les autres comportements réseau du navigateur imposent une lecture plus exigeante. La seule approche sérieuse consiste à auditer non seulement le proxy, mais aussi les mécanismes annexes capables de révéler autre chose que le simple point de sortie web.