Détection des fuites d'IP WebRTC : du bug à la fonctionnalité

WebRTC — Web Real-Time Communication — a été conçu pour permettre les appels vidéo, le partage de fichiers et le transfert de données pair-à-pair directement dans le navigateur. Pour établir ces connexions, les navigateurs doivent découvrir leurs propres interfaces réseau et négocier la connectivité avec des pairs distants. Ce processus fait appel à des serveurs STUN (Session Traversal Utilities for NAT) et TURN (Traversal Using Relays around NAT) qui aident les navigateurs à découvrir leurs adresses IP publiques et à traverser les pare-feux NAT.

L'effet secondaire est puissant : même lorsqu'un utilisateur se connecte via un VPN, la pile WebRTC du navigateur peut révéler l'adresse IP réelle derrière le tunnel. Cela se produit parce que les candidats ICE (Interactive Connectivity Establishment) de WebRTC incluent les adresses des interfaces réseau locales que le VPN ne masque pas.

Comment fonctionne la fuite

Lorsqu'un navigateur crée une RTCPeerConnection et collecte les candidats ICE, il interroge les serveurs STUN pour découvrir son IP publique. Mais il énumère aussi les interfaces réseau locales — y compris l'IP privée de l'adaptateur physique. Si le VPN ne tunnelise le trafic qu'au niveau IP mais ne configure pas la pile WebRTC du navigateur pour utiliser exclusivement l'interface du tunnel, l'IP réelle fuit à travers le candidat host.

Chez tracio.ai, nous sondons ce comportement avec soin. Notre système IP Intelligence crée une requête STUN contrôlée et analyse les candidats ICE que le navigateur renvoie. Lorsque l'IP publique issue de STUN diffère de l'IP que nous voyons sur notre serveur, nous signalons un VPN ou un proxy. Lorsque l'IP de l'interface locale révèle une plage de réseau privée qui contredit la localisation géographique supposée, nous augmentons le suspect score.

Du bug au signal de détection

La plupart des navigateurs axés sur la confidentialité ont corrigé cette fuite — Chrome exige une autorisation explicite de l'utilisateur pour WebRTC, et Firefox propose des réglages pour désactiver l'UDP non proxifié. Mais la course à l'armement continue : certains clients VPN ne configurent pas correctement WebRTC, les anciennes versions de navigateur restent vulnérables, et le schéma comportemental d'une réponse WebRTC « corrigée » par rapport à « fuitante » est en soi un signal utile.

Notre approche traite la réponse WebRTC comme un signal composite : la présence de candidats host, le nombre de candidats ICE renvoyés, les types de candidats (host, srflx, relay) et le temps de réponse contribuent tous à l'empreinte de l'appareil. Même lorsqu'aucune IP ne fuit, le schéma du comportement WebRTC est distinctif.

Sondage des serveurs TURN

Au-delà de STUN, nous sondons également le comportement des serveurs TURN. Les relais TURN sont généralement utilisés lorsque les connexions pair-à-pair directes échouent — courant dans les réseaux d'entreprise derrière des pare-feux stricts. La réponse d'allocation TURN révèle des informations sur le chemin du relais : le protocole de transport (UDP vs TCP vs TLS), l'adresse du relais et la durée de vie de l'allocation.

Notre système SignalProbe envoie des requêtes d'allocation TURN soigneusement élaborées à nos propres serveurs relais. Le temps de réponse, les transports pris en charge et les schémas de succès/échec d'allocation varient selon l'environnement réseau et fournissent une diversité de signaux supplémentaire pour l'empreinte de l'appareil.

Considérations de confidentialité

Nous tenons à être clairs : tracio.ai n'exploite pas les fuites WebRTC pour désanonymiser les utilisateurs. Notre système détecte l'usage d'un VPN et le signale comme un signal de risque. Nous ne stockons ni n'exposons jamais l'adresse IP fuitée. Le signal est binaire : « VPN détecté avec incohérence WebRTC » ou « comportement WebRTC cohérent avec une connexion directe ».

Cette approche donne aux équipes de prévention de la fraude les informations dont elles ont besoin — un visiteur masque sa localisation réelle — sans compromettre la confidentialité individuelle. Le signal aide à détecter les attaques de fraude coordonnées où plusieurs comptes proviennent de la même localisation dissimulée.