# Empêcher les fuites d'adresses IP liées à WebRTC

Guillaume Nibert, Sébastien Tixeuil, Baptiste Polvé, Nana J. Bakalafoua

M'Boussi, Xuan Son Nguyen

► To cite this version:

Guillaume Nibert, Sébastien Tixeuil, Baptiste Polvé, Nana J. Bakalafoua M'Boussi, Xuan Son Nguyen. Empêcher les fuites d'adresses IP liées à WebRTC. RESSI 2024 - Rendez-Vous de la Recherche et de l'Enseignement de la Sécurité des Systèmes d'Information, May 2024, Eppe-Sauvage, France. hal-05077608

HAL Id: hal-05077608

https://hal.sorbonne-universite.fr/hal-05077608v1

Submitted on 21 May 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Empêcher les fuites d'adresses IP liées à WebRTC

Guillaume Nibert*†, Sébastien Tixeuil†‡, Baptiste Polvé*, Nana J. Bakalafoua M'boussi*, Xuan Son Nguyen*

*Snowpack, F-91400 Orsay, France

{guillaume.nibert, baptiste.polve, nana.bakalafoua, xuanson.nguyen}@snowpack.eu

†Sorbonne Université, CNRS, LIP6, F-75005 Paris, France

‡Institut Universitaire de France, F-75005 Paris, France

{sebastien.tixeuil}@lip6.fr

**Résumé**—L'API WebRTC permet la communication en temps réel de flux médias textes, vidéos et audios par l'intermédiaire d'un navigateur web sans nécessiter d'extensions tierces. Cependant, elle n'a pas été conçue en tenant compte de la protection de la vie privée. C'est pourquoi, nous menons une expérience pour analyser les fuites de données privées associées à WebRTC. Nos résultats montrent que, malgré les récentes mises à jour de la spécification WebRTC et de ses implémentations, des adresses IP publiques sensibles peuvent encore être divulguées pendant les communications audio/vidéo, en particulier dans les grands réseaux d'entreprise dépourvus de NAT, et ce même caché derrière un VPN. Pour remédier aux fuites observées, nous avons développé une solution simple, facilement maintenable et multi-plateforme qui confine le navigateur web Mozilla Firefox dans un conteneur Docker. Nous prenons également en compte la possibilité qu'un adversaire malveillant puisse compromettre le navigateur. Nos tests démontrent que notre solution conteneurisée est efficace dans toutes les situations sans restreindre les applications.

**Mots-clefs**—WebRTC, docker, confinement, fuites d'adresses IP, navigateur web, vie privée, réseaux privés virtuels

## I. MOTIVATIONS

Facebook Messenger [7], Discord [10], Jitsi [4], et bien d'autres encore proposent des solutions de communications à grande échelle tirant parti de WebRTC [3]. Dans cet article, nous étudions la révélation d'informations sensibles liées à WebRTC lors d'une utilisation normale du protocole. Nous montrons que l'API WebRTC peut révéler des informations sensibles sur les utilisateurs à leur insu. Nous nous concentrons sur les fuites d'adresses IP lors de l'utilisation d'applications de communication basées sur WebRTC sur des navigateurs web de bureau. La fuite d'adresses IP publiques peut permettre des attaques par déni de service, de géolocaliser un utilisateur, d'identifier son fournisseur d'accès et le type de réseau (mobile ou non) associé. La fuite d'adresses IP privées quant à elle peut révéler des informations sur le réseau local, y compris sur le fournisseur d'accès à Internet, si l'agent se trouve dans un réseau d'entreprise ou domestique, ainsi que les services qui y sont hébergés. Ces adresses peuvent également être utilisées dans d'autres attaques, telles que pour forger des cookies [6]. Ces données sont donc très précieuses pour les attaants.

## II. FUITES D'ADRESSES IP WEBRTC

Supposons qu'Alice et Bob veuillent utiliser l'API WebRTC pour une communication VoIP peer-to-peer. Alice est l'interatrice de la connexion (figure 1). Étapes 1-2, à l'aide du

<figure><img src="image_2.png" /><figcaption>FIGURE 1. Établissement d'une communication média en temps réel Peer-to-Peer derrière des NATs</figcaption></figure>

framework ICE (Interactive Connectivity Establishment) [5], elle contacte un serveur STUN (Session Traversal Utilities for NAT) via son navigateur web, qui lui renvoie son ou ses adresse(s) IP publique(s). Étape 3, elle fournit une liste de candidats ICE contenant ses adresse(s) IP publique(s) et privée(s) sous la forme d'objets SDP (Session Description Protocol) via un serveur de signalisation, qui transmet à son tour cette liste à Bob. Étapes 4-5-6, Bob effectue les mêmes étapes qu'Alice. Étape 7, ils établissent leur connexion, puis échangent leur flux média en peer-to-peer. Si les participants n'utilisent pas le même protocole de transport (TCP/UDP), le transport du flux multimédia entre Alice et Bob est impossible. Un serveur intermédiaire TURN (Traversal Using Relays around NAT) résout ce problème.

En résumé, les adresses collectées par le protocole ICE auprès de la machine initiant une communication WebRTC comprennent les adresses IPv4/IPv6 publiques retournées par le serveur STUN, les adresses IPv4/IPv6 publiques allouées par un serveur TURN et les adresses IPv4/IPv6 publiques et/ou privées attachées aux interfaces physiques et virtuelles.

Les serveurs STUN/ TURN ne connaissent que les adresses IP publiques sources des requêtes reçues. Si les utilisateurs de WebRTC sont cachés derrière un VPN, leur identité devrait rester anonyme. Pourtant, d'autres informations pourraient être récupérées en configurant un enregistrement DNS wildcard pour ce serveur [8]. Avec ou sans VPN, il est impossible de
bloquer une requête STUN/TURN du navigateur web car cette
requête est faite en dehors du framework de signalisation [2].

**Fuite WebRTC:** Tout ou partie de cette liste d'adresses IP peut être envoyée au serveur de signalisation, puis à l'autre pair [9]. Ainsi, un adversaire malveillant peut déployer ses propres serveurs STUN, TURN et de signalisation, ainsi qu'une page web malveillante contenant un code JavaScript appelant l'API WebRTC (exécuté localement sur l'ordinateur du client), pour récupérer toutes les adresses de la victime et les envoyer au serveur de signalisation malveillant.

### III. FUITES D'ADRESSES IP : CONSTAT ET CONFINEMENT

#### A. Architecture du banc d'essai

Nous avons mis en place un système (figure 2) composé :

d'un serveur STUN public et un serveur TURN public :
situés sur le même VPS, mis en œuvre par coturn [1]. Nos
serveurs STUN/TURN n'exploitent pas l'attaque des entrées
DNS de type wildcard décrite par Roesler [8].

d'une page web: accessible en ligne, chargée d'exécuter
un appel à l'API WebRTC pour générer des offres ICE
localement dans le navigateur web appelant. La liste des
candidats est générée et affichée localement.

d'un client web: exécuté soit nativement, soit dans
un conteneur Docker. Pour améliorer la confidentialité de
WebRTC, nous proposons d'isoler le navigateur web dans
un conteneur qui fournit une interface unique attachant une
adresse IPv4 privée et une adresse ULA IPv6 (comparable à
une adresse IPv4 privée), toutes deux pouvant être acheminées
vers l'Internet via des règles NAT. Nous considérons deux
versions du client web, l'une honnête (fonctionnant avec les
paramètres par défaut), et l'autre compromise pour WebRTC.
Docker a été choisi en raison de son avantage multiplateforme.
La solution a été mise en œuvre sur Linux tout en préservant
les fonctionnalités du navigateur telles que l'audio, la caméra,
le partage d'écran, qui sont utiles pour WebRTC. L'utilisateur
exécute un script pour utiliser la solution.

d'un serveur VPN : derrière lequel le client web peut se
cacher en masquant son (ses) adresse(s) IP publique(s).

Une expérience sur notre banc d'essai consiste à demander
au client web d'ouvrir la page web. Lorsque le client le fait,
une analyse du trafic Wireshark est effectuée à la fois sur
le client et sur la machine hébergeant les serveurs STUN et
TURN afin de surveiller les requêtes.

Dans nos expériences, le client est connecté par Wi-Fi
(eduroam) et Ethernet à un réseau universitaire. Il dispose
d'adresses IPv4 et IPv6 publiques directement attachées à ces
deux interfaces. De manière surprenante, cette configuration
réseau n'est pas rare : les réseaux eduroam des deux campus
universitaires testés (environ 1 500 et 30 000 personnes
respectivement) n'ont pas de NAT.

#### B. Résultats

Nous avons analysé les fuites d'adresses IP résultant de
l'utilisation de WebRTC dans diverses situations et avons
conclu qu'aucun des navigateurs web les plus populaires ne
garantit une confidentialité suffisante. Nous constatons qu'il

<figure><img src="image_3.png" /><figcaption>FIGURE 2. Éléments du banc d'essai</figcaption></figure>

existe de grands réseaux d'entreprise dépourvus de NAT et que
ce n'est pas rare, comme le montrent les réseaux eduroam des
deux campus universitaires. Cette situation entraîne une fuite
des adresses IP publiques, même derrière un VPN.

Pour résoudre ces problèmes, nous avons proposé une
solution simple basée sur un conteneur pour permettre l'uti-
lisation de WebRTC sans compromettre la vie privée dans
divers contextes. En particulier, notre isolation de Firefox
dans un conteneur Docker ne fournit qu'une seule interface
réseau et nous permet de protéger l'utilisateur contre les fuites
d'adresses IP et les compromissions pendant la communication
vidéo/audio. Il laisse filtrer moins d'informations sensibles :
seulement les adresses IP privées de l'interface réseau unique
fournie par le conteneur, et les adresses IP publiques fournies
par son FAI. En se cachant derrière un VPN, aucune infor-
mation sensible ne fuit vers des serveurs STUN/TURN tiers,
le serveur de signalisation et l'autre pair. Notre solution est
facile à installer, à utiliser et ne nécessite pas d'ajouter des
extensions ni de désactiver IPv6 au niveau de l'hôte.

#### RÉFÉRENCES

[1] coturn team. Coturn TURN server. https://github.com/coturn/coturn, 2022.

[2] Alexandros Fakis, Georgios Karopoulos, and Georgios Kambourakis. Neither Denied nor Exposed: Fixing WebRTC Privacy Leaks. *Future Internet*, 12(5):92, May 2020.

[3] Cullen Jennings, Henrik Boström, Florent Castelli, and Jan-Ivar Brua-
roey. WebRTC: Real-time communication in browsers, March 2023.

[4] Jitsi. FAQ | Jitsi. https://desktop.jitsi.org/Documentation/FAQ.html, June 2017.

[5] Ari Keränen, Christer Holmberg, and Jonathan Rosenberg. Interactive Connectivity Establishment (ICE) : A Protocol for Network Address Translator (NAT) Traversal. Request for Comments RFC 8445, Internet Engineering Task Force, July 2018.

[6] Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, and Gildas Avoine. Browser Fingerprinting : A Survey. *ACM Trans. Web*, 14(2):8:1–8:33, April 2020.

[7] Christoph Purrer. Messenger Desktop : Faster and Smaller by moving to React Native from Electron. https://developers.facebook.com/blog/post/2023/05/17/messenger-desktop-faster-and-smaller-by-moving-to-react-native-from-electron/, May 2023.

[8] Daniel Roesler. STUN IP Address requests for WebRTC. https://github.com/diafygi/wehrtc-ips, January 2015.

[9] Justin Uberti. WebRTC IP Address Handling Requirements. Request for Comments RFC 8828, Internet Engineering Task Force, January 2021.

[10] Jozsef Vass. How Discord Handles Two and Half Million Concurrent Voice Users using WebRTC. https:// discord.com/blog/how-discord-handles-two-and-half-million-concurrent-voice-users-using-wehrtc, September 2018.