Fuites WebRTC : pourquoi votre vraie adresse peut apparaître même derrière un proxy
WebRTC existe pour que les navigateurs puissent communiquer directement entre eux, pour les appels et le partage d'écran. Pour cela, ils doivent découvrir les adresses auxquelles ils sont joignables, et c'est ce processus de découverte que désigne une « fuite WebRTC ».
Les candidats ICE en un paragraphe
Quand une page crée une RTCPeerConnection et lance une offre, le navigateur rassemble des candidats : des moyens pour un autre pair de le joindre. Un candidat host est l'adresse d'une interface locale. Un candidat server-reflexive (srflx) est l'adresse publique d'où un serveur STUN a vu arriver la requête. Un candidat relay est l'adresse d'un serveur TURN. Chaque candidat est remis à la page dans une ligne de texte contenant l'adresse, ce qui permet à un script de la lire, sans qu'aucun appel n'ait jamais lieu.
Où se situe la fuite
Le candidat srflx est celui qui compte. Pour l'obtenir, le navigateur envoie un petit paquet UDP à un serveur STUN, qui répond avec l'adresse qu'il a vue. Si votre trafic HTTP passe par un proxy mais pas votre trafic UDP, le serveur STUN voit votre vraie connexion, et la page dispose alors d'une adresse qui contredit celle que le serveur web a vue. Ce désaccord est la fuite classique. Une page de diagnostic peut la montrer en comparant les deux.
Notez ce qui se passe et ce qui ne se passe pas. Aucun média n'est capturé. Aucune autorisation de microphone ou de caméra n'intervient. Le paquet part vers le serveur STUN que la page a désigné, si bien que ce serveur, comme tout serveur que vous contactez, voit votre adresse.
Ce que les navigateurs ont changé
Les candidats host exposaient autrefois des adresses LAN privées comme 192.168.1.23, utiles pour prendre l'empreinte d'un réseau domestique. Les navigateurs modernes les remplacent par des noms mDNS générés aléatoirement et se terminant par .local, de sorte qu'une page voit un nom opaque plutôt qu'une adresse. Un diagnostic qui indique « masqué par le navigateur » décrit ces candidats. Firefox et Brave proposent aussi des réglages qui empêchent la collecte de candidats en dehors du proxy, et certaines extensions bloquent entièrement WebRTC.
Configurations compatibles avec un proxy
Trois approches fonctionnent, avec des coûts différents. Désactiver WebRTC empêche la fuite et casse tous les sites qui en ont besoin. Forcer WebRTC à n'utiliser que la route du proxy (le mode « proxy-safe » de certains navigateurs) maintient les appels fonctionnels quand le proxy prend en charge UDP ou TURN, et sinon ne donne aucun candidat public. Laisser WebRTC se comporter normalement n'est correct que si le proxy transporte tout le trafic, comme le fait généralement un VPN au niveau du système.
La bonne approche dépend de la tâche. Pour un profil de navigateur isolé qui doit apparaître à un seul endroit, la règle est simple : l'adresse que WebRTC expose doit être la même que celle que voit le serveur web, ou aucune. Tout le reste est une contradiction qu'un site peut remarquer sans aucun outil particulier.
Lire le résultat
Un diagnostic affiche les candidats observés en quelques secondes et compare tout candidat public à l'adresse depuis laquelle la page a été atteinte. « Aucune exposée » avec quelques candidats masqués est un résultat normal et sain pour un navigateur qui garde WebRTC à l'intérieur du proxy. Une adresse publique différente de celle de la page est ce qu'il faut corriger.
