Un proxy peut couvrir le trafic HTTP tandis que WebRTC échange des adresses candidates via STUN/ICE sur UDP. Cet article explique quand des adresses locales ou privées peuvent être exposées et comment garder cohérents la sortie réseau et l’environnement du navigateur.
Vous avez configuré un proxy, et une page de vérification d’IP affiche la région et le fournisseur attendus. L’identité réseau semble propre. Pourtant, lorsque vous ouvrez un test de fuite, la section WebRTC passe au rouge et affiche l’adresse de votre véritable connexion Internet.
Inutile de changer immédiatement de proxy. Dans la plupart des cas, le problème ne vient pas de sa qualité, mais du trafic qu’il ne prend pas en charge.
Le proxy gère HTTP, tandis que WebRTC emprunte une autre voie
Un proxy agit au niveau réseau. Qu’il prenne la forme d’une extension de navigateur ou d’un tunnel système, il traite les requêtes HTTP/HTTPS et envoie ce trafic via la sortie du proxy.
WebRTC fonctionne différemment. Il s’agit d’une capacité de communication en temps réel intégrée au navigateur. Pour permettre aux appels audio/vidéo et aux transferts P2P de trouver un chemin adapté, le navigateur peut envoyer activement des requêtes STUN à des serveurs externes — en substance : « Quelle adresse voyez-vous pour moi ? » — puis organiser les réponses en candidats ICE transmis à la page web. Ces requêtes utilisent UDP, un canal indépendant du tunnel HTTP.
Une incohérence apparaît alors : les requêtes web sortent par le proxy, tandis que le navigateur peut aussi signaler une adresse locale. Penser qu’un proxy correctement configuré suffit à nettoyer toute l’identité réseau est le point de départ le plus fréquent de ce problème.
Il n’y a pas que l’IP publique qui peut être exposée
Les candidats ICE contiennent généralement deux types d’adresses. Le premier est l’adresse publique, c’est-à-dire la sortie de votre véritable fournisseur d’accès. Le second est une adresse locale, par exemple une adresse privée commençant par 192.168, parfois accompagnée de l’adresse d’une carte réseau virtuelle.
Une adresse de réseau privé ne prouve pas grand-chose à elle seule : presque tous les ordinateurs en ont une. Mais elle peut être suffisamment stable pour que des candidats qui se recoupent à plusieurs reprises entre différents comptes fournissent à une plateforme un signal supplémentaire permettant de les associer au même appareil. L’adresse publique est plus directe : elle renvoie au fournisseur réel et à une zone géographique approximative. Le niveau de précision dépend de la plateforme, mais le principe est clair : plus l’adresse est authentique, plus le rapprochement est facile.
Dans quels cas un site peut-il réellement la lire ?
Tous les sites ne tentent pas de le faire. L’échange d’adresses exige que la page crée activement un objet RTCPeerConnection, ce dont une page de contenu ordinaire n’a généralement pas besoin.
On retrouve surtout cette pratique sur plusieurs catégories de sites : les services nécessitant des communications en temps réel, comme les visioconférences, le support client en ligne et certaines pages de diffusion en direct ; les sites qui dépendent fortement de la publicité ou de la lutte contre la fraude ; et les plateformes dotées de systèmes de contrôle des risques plus complets. La lecture se fait hors de l’interface visible et, une fois les données collectées, vous n’êtes généralement pas informé de leur utilisation ultérieure.
Il existe aussi un cas indépendant du site. Pendant le bref intervalle où le proxy se reconnecte ou change de nœud, une requête STUN émise par le navigateur peut passer par le réseau local. La fenêtre est courte, mais suffisante pour qu’une observation soit enregistrée.
Trois scénarios d’échec fréquents
Les proxies sous forme d’extension de navigateur ne prennent généralement en charge que les requêtes HTTP/HTTPS. UDP reste hors de leur périmètre, et cocher une option « globale » dans l’interface n’y change rien.
Un proxy global au niveau du système semble plus complet, puisqu’il couvre le trafic de tout l’appareil. Toutefois, la collecte des adresses candidates peut se lier directement à une interface réseau locale et contourner la table de routage du système, laissant une faille dans le tunnel à ce stade.
Le troisième problème n’est pas seulement technique, mais tient à l’évolution des pratiques. Les systèmes de gestion du risque utilisent de plus en plus les adresses WebRTC comme l’un des signaux permettant d’associer des comptes. Des données qui n’étaient auparavant pas mesurées, ou simplement ignorées, peuvent désormais entrer dans l’évaluation.
L’objectif est une sortie cohérente, pas seulement un interrupteur désactivé
Plusieurs approches sont possibles. Si un usage ne nécessite aucune communication en temps réel, désactiver WebRTC est la solution la plus simple, au prix de la perte de fonctions telles que les appels vidéo ou le support client en ligne.
Si ces fonctions doivent rester disponibles, une pratique courante consiste à faire en sorte que l’adresse renvoyée au niveau WebRTC corresponde à la sortie du proxy. Une solution plus robuste consiste à faire transiter aussi les requêtes STUN par le canal du proxy afin que l’interface n’expose pas l’adresse locale. Pour les usages nécessitant du P2P ou des appels vidéo, l’ensemble du trafic UDP doit passer par le proxy, et pas seulement la couche HTTP.
Une erreur fréquente consiste à penser que désactiver WebRTC suffit à rendre l’environnement propre. Ce qui compte, c’est la cohérence entre la sortie réseau, la résolution DNS, l’appartenance de l’IP et l’ASN, le fuseau horaire et la langue, ainsi que les caractéristiques de l’appareil. Toute divergence peut produire un signal anormal ; WebRTC n’est que l’un des éléments les plus faciles à oublier.
La vérification est simple. Effectuez un test après avoir changé de nœud, puis un autre avant d’utiliser réellement l’environnement : ouvrez un test de fuite et vérifiez si la section WebRTC affiche la sortie du proxy, une adresse locale ou l’adresse publique réelle. Une vérification IP classique ne montre pas cette information.
Les solutions d’isolation au niveau du moteur du navigateur peuvent définir une politique d’adresse WebRTC distincte pour chaque environnement et l’associer à la sortie réseau correspondante. PurpleMark fournit ce type de capacité. Si plusieurs environnements partagent la même sortie ou si leurs politiques d’adresse sont incohérentes, l’intérêt de l’isolation diminue fortement.
Ceci est uniquement une explication technique. Utilisez les outils concernés dans le respect des règles des plateformes et des lois locales.
