Fuite IP WebRTC : ce que c'est et comment l'empêcher

Introduction

WebRTC est une technologie de navigateur qui permet la communication en temps réel : appels vidéo, chat vocal, partage de fichiers pair-à-pair. Pour établir ces connexions, les navigateurs utilisent le protocole ICE (Interactive Connectivity Establishment), qui collecte les adresses des interfaces réseau et les échange avec les pairs. Le problème est que ICE collecte vos adresses IP réelles, y compris les IP du réseau local et votre IP publique, et les rend disponibles via JavaScript. Cela se produit en dehors du chemin proxy HTTP normal, ce qui signifie qu'un proxy seul ne vous protège pas.

BotBrowser contrôle le comportement ICE de WebRTC au niveau du moteur du navigateur. Au lieu de désactiver entièrement WebRTC (ce qui est en soi un signal détectable), BotBrowser garantit que les candidats ICE ne contiennent que des adresses IP cohérentes avec votre identité de proxy.

Impact sur la vie privée

Les fuites IP WebRTC sont l'une des failles de confidentialité les plus connues de la technologie des navigateurs. Lorsqu'une page web initie une connexion pair WebRTC, le navigateur collecte des candidats ICE depuis chaque interface réseau disponible. Ces candidats contiennent :

• Adresses IP locales : l'IP privée de votre machine sur le réseau local (par ex. 192.168.1.100)
• Adresse IP publique : votre véritable IP publique depuis les réponses du serveur STUN
• Adresses IPv6 : si disponibles, votre adresse IPv6 complète

Un site web peut collecter ces candidats via l'API RTCPeerConnection sans aucune interaction utilisateur ni demande de permission. Même si vous routez tout le trafic HTTP via un proxy, les requêtes STUN de WebRTC voyagent directement vers le serveur STUN, révélant votre véritable IP publique.

Cela crée un chemin direct vers la désanonymisation. Un système de pistage qui voit votre IP de proxy dans les requêtes HTTP mais votre vraie IP dans les candidats WebRTC sait exactement ce qui se passe. L'incohérence elle-même est un signal fort.

Contexte technique

Comment fonctionne la collecte de candidats ICE

Lorsque JavaScript crée un RTCPeerConnection, le navigateur commence à collecter des candidats ICE. Ce processus implique :

1. Candidats hôte : le navigateur énumère les interfaces réseau locales et collecte leurs adresses IP. Celles-ci deviennent des candidats "host".

2. Candidats réflexifs serveur : le navigateur envoie des requêtes de binding STUN (Session Traversal Utilities for NAT) aux serveurs STUN configurés. Le serveur STUN répond avec l'adresse IP publique qu'il observe, créant des candidats "srflx".

3. Candidats relais : si des serveurs TURN (Traversal Using Relays around NAT) sont configurés, le navigateur établit des chemins relais à travers eux, créant des candidats "relay".

Chaque type de candidat expose différentes informations réseau. Les candidats hôte révèlent les IP locales. Les candidats réflexifs serveur révèlent votre IP publique. La combinaison des trois fournit une carte détaillée de votre topologie réseau.

Pourquoi les extensions ne peuvent pas résoudre complètement ce problème

Les extensions de navigateur qui tentent de contrôler WebRTC ont des limites fondamentales :

• Désactiver entièrement WebRTC empêche la collecte ICE mais crée une empreinte détectable. Les sites peuvent vérifier l'absence de RTCPeerConnection et le signaler.
• Bloquer les requêtes STUN au niveau de l'extension peut manquer les requêtes initiées avant le chargement de l'extension ou depuis les service workers.
• Modifier les candidats ICE via le monkey-patching JavaScript est fragile. Les vrais candidats sont générés en code natif avant que JavaScript ait une chance de les intercepter.

Le contrôle au niveau du moteur est la seule approche qui peut modifier la génération des candidats ICE à la source, avant que tout JavaScript sur la page puisse observer les valeurs originales.

Approches courantes et leurs limites

Désactiver WebRTC dans les paramètres du navigateur

Certains navigateurs permettent de désactiver WebRTC via des flags (par ex. media.peerconnection.enabled dans Firefox). Cela arrête toute la collecte ICE mais casse aussi les fonctionnalités légitimes de WebRTC comme la vidéoconférence. Plus important, l'absence des API WebRTC est un signal d'empreinte distinct. Un navigateur qui manque RTCPeerConnection se distingue.

Extensions de contrôle WebRTC

Les extensions comme WebRTC Leak Prevent ou uBlock Origin peuvent restreindre WebRTC à certaines plages IP. Cependant, les extensions opèrent dans la couche JavaScript après que le moteur du navigateur a déjà collecté les candidats. Elles peuvent intercepter le callback onicecandidate, mais les candidats originaux existent en mémoire. Certaines approches d'extensions créent aussi des effets secondaires détectables : chaînes de prototypes modifiées, motifs de timing altérés ou propriétés manquantes sur l'objet RTCPeerConnection.

Protection au niveau VPN

Un VPN route tout le trafic système, y compris les requêtes STUN, à travers le tunnel VPN. Cela empêche le serveur STUN de voir votre vraie IP. Cependant, les VPN ne contrôlent pas les candidats ICE locaux (hôte). Votre IP de réseau local (par ex. 192.168.x.x) est toujours collectée et exposée. Pour certains scénarios de pistage, les IP locales contribuent à un identifiant stable.

L'approche de BotBrowser au niveau du moteur

BotBrowser modifie la génération des candidats ICE à l'intérieur de la pile réseau de Chromium. C'est fondamentalement différent de toutes les approches ci-dessus :

• WebRTC reste pleinement fonctionnel. RTCPeerConnection existe et fonctionne normalement.
• Les candidats ICE sont générés avec des informations IP contrôlées dès le départ.
• Aucune modification visible en JavaScript n'existe sur les objets WebRTC.
• Le comportement STUN/TURN est contrôlé au niveau réseau, pas intercepté après coup.

L'approche de BotBrowser

Le flag --bot-webrtc-ice

Le flag --bot-webrtc-ice de BotBrowser (ENT Tier1) contrôle quels serveurs ICE sont utilisés et quelles informations IP apparaissent dans les candidats :

# Utiliser le serveur STUN de Google (preset)
chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="google"

# Utiliser des serveurs STUN et TURN personnalisés
chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="custom:stun:stun.example.com:3478,turn:turn.example.com:3478"

Le preset google configure stun:stun.l.google.com:19302, qui est la configuration STUN la plus couramment observée dans les navigateurs Chrome normaux.

Fonctionnement avec les proxys

Combiné avec --proxy-server, BotBrowser garantit que :

1. Les requêtes STUN passent par le proxy, donc le serveur STUN voit l'IP du proxy
2. Les candidats ICE ne contiennent que l'IP du proxy comme adresse publique
3. Les IP du réseau local n'apparaissent pas dans les candidats hôte
4. L'empreinte WebRTC correspond à ce qu'un utilisateur normal derrière ce proxy produirait

UDP sur SOCKS5 (ENT Tier3)

Pour les utilisateurs ENT Tier3, BotBrowser supporte SOCKS5 UDP ASSOCIATE. Cela tunnel le trafic QUIC et les sondes STUN sur le proxy SOCKS5 automatiquement lorsque le proxy supporte UDP :

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080"

Aucun flag supplémentaire n'est nécessaire. Si le proxy SOCKS5 supporte UDP ASSOCIATE, BotBrowser tunnel le trafic STUN à travers automatiquement.

Configuration WebRTC via le profil

Le comportement WebRTC peut aussi être contrôlé via la configuration du profil :

# Utiliser les paramètres WebRTC définis par le profil
chrome --bot-profile="/path/to/profile.enc" \
       --bot-config-webrtc=profile

# Désactiver entièrement WebRTC (non recommandé pour la cohérence)
chrome --bot-profile="/path/to/profile.enc" \
       --bot-config-webrtc=disabled

Le paramètre profile utilise la configuration WebRTC que le profil définit. Le paramètre disabled désactive WebRTC, mais cela crée un signal détectable et ne devrait être utilisé que lorsque la fonctionnalité WebRTC n'est véritablement pas nécessaire.

Configuration et utilisation

Configuration complète de confidentialité (CLI)

Combinez la protection WebRTC avec les paramètres de proxy, DNS et empreinte :

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="google" \
       --bot-local-dns \
       --bot-config-timezone="America/New_York" \
       --bot-config-locale="en-US"

Intégration Playwright

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-webrtc-ice=google',
      '--bot-local-dns',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Intégration Puppeteer

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-webrtc-ice=google',
      '--bot-local-dns',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Vérification

Après le lancement de BotBrowser avec la protection WebRTC :

1. Visitez un site de test de fuite WebRTC (comme browserleaks.com/webrtc)
2. Vérifiez qu'aucune adresse IP locale (192.168.x.x, 10.x.x.x) n'apparaît dans les candidats ICE
3. Vérifiez que seule l'IP du proxy apparaît comme adresse publique
4. Confirmez que votre véritable IP publique n'est visible dans aucun candidat
5. Testez que les fonctionnalités WebRTC fonctionnent toujours (l'API devrait être présente et fonctionnelle)

Vous pouvez aussi vérifier programmatiquement :

const candidates = await page.evaluate(() => {
  return new Promise((resolve) => {
    const ips = [];
    const pc = new RTCPeerConnection({
      iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
    });
    pc.createDataChannel('test');
    pc.onicecandidate = (e) => {
      if (e.candidate) {
        const match = e.candidate.candidate.match(/([0-9]{1,3}\.){3}[0-9]{1,3}/);
        if (match) ips.push(match[0]);
      } else {
        resolve(ips);
      }
    };
    pc.createOffer().then(o => pc.setLocalDescription(o));
  });
});
console.log('ICE candidate IPs:', candidates);

Bonnes pratiques

1. Combinez toujours --bot-webrtc-ice avec --proxy-server. La protection WebRTC n'a de sens que lorsque vous routez le trafic via un proxy. Sans proxy, votre vraie IP est déjà visible dans les requêtes HTTP.

2. Utilisez le preset "google" sauf si vous avez des besoins spécifiques. Le serveur STUN de Google est la configuration la plus couramment observée et produit les candidats ICE les plus naturels.

3. Ajoutez --bot-local-dns pour une confidentialité réseau complète. WebRTC et DNS sont les deux chemins de fuite réseau les plus courants. Fermer les deux garantit une protection complète.

4. Ne désactivez pas WebRTC sauf si absolument nécessaire. Désactiver WebRTC crée un signal d'empreinte détectable. L'approche contrôlée de BotBrowser garde WebRTC fonctionnel tout en protégeant votre IP.

5. Testez après chaque changement de configuration. Le comportement WebRTC dépend de l'interaction entre proxy, serveur ICE et configuration réseau. Vérifiez toujours après les changements.

Questions fréquentes

BotBrowser casse-t-il les appels vidéo WebRTC ? Non. WebRTC reste pleinement fonctionnel. Les appels vidéo, le chat vocal et les connexions pair-à-pair fonctionnent tous normalement. BotBrowser contrôle uniquement quelles adresses IP apparaissent dans les candidats ICE.

Quelle est la différence entre --bot-webrtc-ice et --bot-config-webrtc ? Le flag --bot-webrtc-ice contrôle la configuration du serveur ICE et l'exposition IP. Le flag --bot-config-webrtc contrôle si WebRTC utilise les paramètres du profil, les paramètres réels du système, ou est désactivé entièrement.

Ai-je besoin de --bot-webrtc-ice si j'utilise un VPN ? Un VPN empêche les serveurs STUN de voir votre vraie IP publique, mais les candidats hôte locaux peuvent encore être exposés. BotBrowser fournit un contrôle plus complet sur tous les types de candidats.

Les sites web peuvent-ils détecter que les candidats ICE sont contrôlés ? BotBrowser modifie la génération des candidats au niveau du moteur. Les candidats ICE sont identiques à ceux produits par un navigateur derrière un proxy avec cette IP. Il n'y a pas d'artefacts visibles en JavaScript.

Qu'en est-il des fuites IPv6 via WebRTC ? BotBrowser contrôle la génération de candidats IPv4 et IPv6. Les adresses IPv6 de vos interfaces réseau réelles n'apparaissent pas dans les candidats ICE.

L'UDP sur SOCKS5 nécessite-t-il une configuration proxy spéciale ? Le proxy doit supporter SOCKS5 UDP ASSOCIATE (RFC 1928). BotBrowser détecte cette capacité automatiquement. Aucun flag supplémentaire n'est nécessaire au-delà de --proxy-server.

Résumé

Les fuites IP WebRTC sont une préoccupation significative de confidentialité que les proxys seuls ne traitent pas. BotBrowser contrôle la génération des candidats ICE au niveau du moteur du navigateur, garantissant que seules les adresses IP cohérentes avec le proxy apparaissent dans les candidats WebRTC tout en gardant WebRTC pleinement fonctionnel.

Pour une configuration complète de confidentialité réseau, combinez la protection WebRTC avec Proxy Configuration et DNS Leak Prevention. Pour gérer plusieurs identités avec différentes configurations réseau, voir Multi-Account Browser Isolation.