Mon IP : adresse, fuite DNS et WebRTC

Ce que ce service voit, et combien de temps

Un outil de vie privée ne doit pas garder plus que le nécessaire. Voici, pour chaque test, ce que mon serveur reçoit et ce qu’il en fait.

• Votre adresse IP. Cloudflare, qui relaie les pages de privova.fr, transmet à mon serveur l’adresse d’où vous venez (en-tête CF-Connecting-IP), et je vous la renvoie. Sur cette API, le serveur web n’écrit aucun journal d’accès et le programme ne garde rien : l’adresse n’est ni enregistrée ni stockée. Cloudflare, comme pour tout le site, voit passer les requêtes.
• Le test DNS. Au clic, mon serveur tire un identifiant aléatoire, valable 10 minutes, et votre navigateur essaie de charger 6 images à des adresses de la forme identifiant-1.dnsleak.privova.fr. Pour cela, il demande à son serveur DNS (le résolveur) de traduire ces noms, et ce résolveur finit par interroger mon serveur DNS, seul serveur faisant autorité pour dnsleak.privova.fr. Mon serveur note, pour cet identifiant, l’adresse du résolveur qui l’interroge et le numéro de la sonde. Il ne reçoit pas votre adresse, et il ne lit pas l’information de sous-réseau client que certains résolveurs ajoutent (RFC 7871).
• Combien de temps. En mémoire vive uniquement, jamais sur disque ni dans un journal : les adresses des résolveurs rattachées à l’identifiant, et le numéro de réseau (AS) de votre adresse pour pouvoir comparer. Tout disparaît au bout de 10 minutes, quand vous cliquez sur « Effacer ce test maintenant », quand vous quittez la page (elle demande l’effacement, au mieux selon votre navigateur) ou si le service redémarre.
• Le test WebRTC. Votre navigateur envoie un paquet STUN à mon serveur (port UDP 53) qui répond avec l’adresse et le port d’où il l’a reçu. Rien n’est enregistré, et aucun serveur STUN tiers n’intervient. Pour afficher le réseau d’une adresse trouvée, la page me la renvoie dans une requête de consultation de ma base, sans conservation.
• Contre les abus. Mon serveur DNS ne répond que pour dnsleak.privova.fr (jamais pour un autre nom, ce n’est pas un résolveur ouvert) et limite le nombre de requêtes par adresse source. Ces compteurs restent en mémoire une minute au plus ; le serveur web limite aussi le débit de l’API, également en mémoire.
• Sur votre appareil. Aucun cookie, rien dans le stockage du navigateur, aucune ressource chargée chez un tiers. Les informations de navigateur affichées plus haut (langues, fuseau horaire, user-agent) sont lues localement et ne me sont pas envoyées.

Ce que n’importe quel site voit quand vous le visitez

D’abord votre adresse IP, parce qu’un serveur doit savoir où renvoyer sa réponse. Elle indique le réseau d’où vous venez (un fournisseur d’accès, un opérateur mobile, un hébergeur, un VPN). La CNIL range l’adresse IP parmi les données personnelles ; en revanche, le pays affiché par cet outil est celui que ma base associe au bloc d’adresses, pas votre position.

Ensuite ce que dit votre navigateur : langues, fuseau horaire, user-agent, tels qu’ils sont affichés dans l’outil. Un site peut les recouper entre eux et avec le pays de l’adresse. Cette adresse n’est pas dans la page, elle est dans le trafic : un navigateur ne peut pas la cacher sans passer par un relais (VPN, proxy, réseau Tor).

Ce qu’un VPN change, et ce qu’il ne change pas

Ce qu’il change.

• L’adresse que voient les sites devient celle du serveur du VPN. Vous pouvez le vérifier ici : activez le VPN, rechargez la page, comparez.
• Votre fournisseur d’accès voit une connexion chiffrée vers le VPN, plus les sites que vous visitez, à condition que vos requêtes DNS passent aussi par le tunnel. C’est exactement ce que le test de fuite DNS vérifie.

Ce qu’il ne change pas.

• Le fournisseur de VPN voit à son tour ce que voyait votre fournisseur d’accès : vous déplacez la confiance, vous ne la supprimez pas. Les requêtes DNS révèlent les noms de domaine consultés au résolveur qui les traite (RFC 7626) ; chiffrer le trajet vers ce résolveur (DNS sur HTTPS, RFC 8484) n’empêche pas le résolveur lui-même de les voir.
• Vos comptes, vos cookies et l’empreinte de votre navigateur : un site où vous êtes connecté sait qui vous êtes, quelle que soit l’adresse.
• Ce que le fournisseur de VPN conserve. Je ne teste pas les VPN et je ne peux pas le vérifier ; je m’en tiens à leurs documents publics.

Tester son VPN en quatre étapes

1. VPN coupé, lancez le test et notez l’adresse, le réseau et les résolveurs DNS affichés.
2. Activez le VPN, sans recharger la page, puis lancez un second test.
3. L’adresse et le réseau doivent avoir changé pour ceux du VPN. Si l’adresse reste la vôtre, le VPN n’achemine pas ce trafic.
4. Lisez les résolveurs DNS et le test WebRTC avec les deux sections qui suivent : ce sont eux qui disent s’il y a une fuite.

Lire un résultat de fuite DNS

Quand vous ouvrez un site, votre appareil demande à un résolveur DNS de transformer le nom en adresse. Ce résolveur voit tous les noms que vous demandez. Sans VPN, c’est en général celui de votre fournisseur d’accès (réglé par la box ou le réseau) ou un résolveur public que vous avez choisi. Avec un VPN, vous voulez que ces demandes passent aussi par le tunnel : il y a « fuite DNS » quand elles continuent d’aller au résolveur habituel. La liste de l’outil donne les résolveurs qui ont interrogé mon serveur, avec leur réseau.

Deux réserves. Le résolveur affiché est le dernier maillon vu par mon serveur : derrière lui, il peut y avoir un relais (une box qui redirige vers le fournisseur d’accès, par exemple). Et je ne sais pas si vous utilisez un VPN : faites un test VPN coupé, puis un second VPN activé, sans recharger la page, pour que la comparaison se fasse toute seule.

Lire le test WebRTC

WebRTC permet à un navigateur d’établir des appels directs (visioconférence). Pour trouver un chemin, il collecte des adresses candidates : les adresses locales de l’appareil (type host) et l’adresse publique qu’un serveur STUN lui renvoie (type srflx, voir la documentation de MDN). Le script d’une page peut les lire. La RFC 8828 (§ 3) range ce que cela révèle de plus qu’une requête HTTP en trois cas : l’adresse publique du fournisseur d’accès quand un VPN n’achemine pas tout le trafic, les adresses privées derrière un routeur, et l’adresse publique contournant un proxy.

• Même adresse publique que celle vue par ce site : WebRTC ne révèle rien de plus.
• Autre adresse publique, de la même famille : avec un VPN, c’est le signe d’une fuite WebRTC. Le réseau affiché à côté indique si c’est celui de votre fournisseur d’accès.
• Adresse d’une autre famille (IPv6 alors que la page a vu de l’IPv4, ou l’inverse) : à vérifier ; certains VPN ne gèrent qu’une des deux familles.
• Aucune adresse publique : WebRTC est désactivé, ou le trafic UDP vers mon serveur STUN (port 53) est filtré. Le test n’est alors pas concluant.

Si le test montre une fuite avec votre VPN, regardez d’abord si l’application propose une protection WebRTC. Sinon, le navigateur permet de restreindre ou de couper WebRTC : Chrome n’expose pas de réglage dans ses paramètres, à ma connaissance, seulement une API réservée aux extensions (webRTCIPHandlingPolicy), et Firefox a le réglage media.peerconnection.enabled dans about:config. Dans les deux cas, couper WebRTC empêche les appels vidéo dans le navigateur.

Ce que cet outil ne sait pas faire

• Voir en même temps votre adresse IPv4 et votre adresse IPv6 : la page affiche celle de la connexion qu’elle a reçue (le test WebRTC peut en révéler une autre).
• Connaître le résolveur que votre appareil utilise réellement : je vois ceux qui interrogent mon serveur, pas ce qu’il y a avant.
• Détecter un trafic qui sortirait du tunnel par un autre chemin que le DNS et WebRTC.
• Dire si votre VPN conserve des journaux.

Sources et données

• Réseau (AS) et pays : base iptoasn.com, publiée dans le domaine public (licence PDDL 1.0), chargée en mémoire par mon serveur ; la date de la copie utilisée s’affiche dans l’outil. Le pays est celui que la base associe au bloc d’adresses : ce n’est pas une localisation.
• Cloudflare, en-têtes HTTP (CF-Connecting-IP).
• RFC 7626, considérations sur la vie privée du DNS ; RFC 8484, DNS sur HTTPS ; RFC 7871, sous-réseau client dans les requêtes DNS.
• RFC 8828, gestion des adresses IP par WebRTC ; RFC 8489, protocole STUN ; MDN, connectivité WebRTC.
• CNIL, définition de la donnée personnelle.
• Chrome, API privacy des extensions.

Cet outil est écrit et hébergé par moi, sans service tiers. Si quelque chose vous paraît inexact, écrivez-moi : je corrige et je change la date de mise à jour.