Qu’est-ce qu’une fuite DNS ou WebRTC ?

Voyez le DNS comme l’annuaire téléphonique d’Internet. Chaque fois que vous saisissez une adresse web, votre appareil ne peut pas utiliser le nom tel quel. Il doit transformer ce nom en un numéro, une adresse IP, et pour cela il interroge un résolveur DNS. Sur la plupart des réseaux, ce résolveur appartient à celui qui gère le réseau. C’est votre fournisseur d’accès à la maison, ou l’équipe informatique au travail.

Ainsi, la petite requête qui demande « où se trouve example.com ? » voyage jusqu’à une machine que vous ne contrôlez pas, et elle transporte le nom du site que vous vous apprêtez à ouvrir. Une fuite DNS, c’est quand cette résolution échappe à la protection qui était censée vous couvrir. Vous utilisez peut-être un outil qui chiffre le trafic lui-même, mais si la résolution du nom d’hôte part toujours vers le résolveur du réseau, le réseau apprend malgré tout le nom de chaque site que vous atteignez.

L’important est de remarquer ce qui fuite. Une fuite DNS ne révèle pas ce que vous avez envoyé ou lu. Elle révèle où vous alliez, ce qui, pour beaucoup de gens, est justement la partie sensible.

WebRTC est un ensemble de fonctionnalités intégrées à tous les navigateurs modernes pour que les appels vidéo, les discussions vocales et certains partages de fichiers directs fonctionnent sans application distincte. Pour relier 2 personnes, WebRTC doit d’abord déterminer les adresses auxquelles chaque côté peut être joint. Il rassemble des adresses candidates, dont l’adresse locale de votre appareil sur le réseau et, avec l’aide d’un serveur appelé serveur STUN, votre adresse IP publique.

Le piège, c’est que cette collecte d’adresses peut s’exécuter directement depuis le JavaScript d’une page, et passer par son propre chemin plutôt que par celui qu’empruntent vos autres outils. Une page peut donc discrètement demander au navigateur « quelle est la véritable adresse IP de ce visiteur ? » et obtenir une réponse, même quand la connexion principale semble verrouillée.

C’est une fuite WebRTC. Elle peut livrer votre véritable adresse IP à une page web via une fonctionnalité que vous n’avez jamais choisi d’activer, et c’est précisément ainsi qu’elle a piégé des gens qui pensaient qu’un seul outil les couvrait entièrement.

Placez-les côte à côte. Une fuite DNS indique au réseau les noms des endroits où vous allez. Une fuite WebRTC indique à un site web le numéro qui identifie votre connexion. Si vous êtes sur un appareil ou un réseau que quelqu’un d’autre contrôle, cette combinaison est tout l’enjeu.

Si vous vous tournez vers un proxy ou un outil de confidentialité, c’est d’abord pour garder l’un de ces 2 faits pour vous. Une fuite dans l’un ou l’autre canal réduit cet effort à néant, sans le moindre signal. Rien ne semble cassé. La page se charge quand même. Vous avez simplement livré plus que vous ne le vouliez.

• Fuite DNS : ce qui fuite, c’est le nom du site ; qui le voit, c’est le réseau (votre fournisseur d’accès ou le résolveur local) ; et vous la repérez avec un test de fuite DNS.
• Fuite WebRTC : ce qui fuite, c’est votre véritable adresse IP ; qui la voit, c’est la page web que vous visitez ; et vous la repérez avec un test de fuite WebRTC.

C’est là qu’un proxy web à réécriture gagne sa place, et là qu’il vaut mieux être précis sur ce qu’il fait et ce qu’il ne fait pas.

Lorsque vous ouvrez un site via TrickyBird, vous chargez en réalité l’adresse de TrickyBird elle-même. L’adresse de la cible est encodée dans le chemin, si bien que votre navigateur ne contacte que TrickyBird. La résolution du site que vous voulez vraiment se fait de notre côté, pas sur votre appareil. En clair, le nom d’hôte de la cible reste en dehors des requêtes DNS que votre navigateur envoie au réseau qui vous entoure. Donc si vous vous demandez si un proxy web masque votre adresse IP et tient vos destinations à l’écart du résolveur local, c’est précisément le travail que fait ce dispositif. C’est ce même principe de zéro fuite de domaine qui garde le nom de la cible hors de la barre d’adresse et hors de la page (voyez quels sites s’affichent proprement en ce moment sur /status). Il n’y a rien à télécharger et aucune application, ce qui compte quand le blocage se trouve sur un appareil qui ne vous laissera rien installer.

Il y a une limite honnête qu’il vaut la peine d’énoncer clairement. La passerelle doit elle-même résoudre la cible et s’y connecter pour la récupérer : cette étape-là n’est donc pas cachée. Nous en conservons une trace volontairement réduite : une adresse IP raccourcie, coupée en /24 ou /48 pour qu’elle désigne un quartier plutôt qu’une maison précise, plus le nom d’hôte de destination et des données de réponse basiques, pendant 48 heures au maximum. Le détail complet de la conservation et de la suppression figure sur /security. C’est une journalisation minimale, vérifiable et de courte durée, et l’important est que vous pouvez la contrôler au lieu de nous croire sur parole. C’est une posture très différente d’une promesse absolue que vous n’avez aucun moyen de vérifier. Voyez comment les politiques se comparent.

Non, et sur ce point il vaut mieux être clair. TrickyBird réécrit les pages qu’il sert, mais il n’intercepte pas WebRTC. WebRTC fonctionne comme un sous-système du navigateur à part, sur son propre chemin réseau, si bien qu’une page que vous ouvrez à travers le proxy peut toujours joindre directement un serveur STUN et récupérer votre véritable adresse IP, même pendant que le reste de cette page se charge à travers TrickyBird.

Traitez donc WebRTC comme quelque chose que vous coupez vous-même, pas comme quelque chose dont le proxy s’occupe pour vous. Coupez-le dans votre navigateur avec les étapes ci-dessous, puis lancez un test de fuite WebRTC sur l’appareil et le réseau précis qui vous importent, pour confirmer que votre véritable adresse IP n’apparaît plus. Mieux vaut le vérifier vous-même que faire confiance à une affirmation, celle-ci comprise.

Vous n’êtes pas obligé de vous en remettre à un seul outil. WebRTC peut aussi se brider au niveau du navigateur, et il vaut la peine de savoir comment. Dans Firefox, ouvrez about:config et réglez media.peerconnection.enabled sur false, ce qui désactive la fonctionnalité. Chrome n’offre pas de bascule native : on se tourne alors en général vers une extension bien notée qui bloque WebRTC, même si, sur un appareil administré, vous n’aurez peut-être pas le droit d’en ajouter une.

Sur mobile, la situation varie selon la plateforme. Safari sur iOS est plus restrictif sur ce que WebRTC livre à une page, tandis que Chrome sur Android se comporte à peu près comme sur ordinateur. Donc si vous vous demandez si iOS fuit via WebRTC : cela peut arriver, simplement moins librement que sur un navigateur de bureau.

Le DNS a lui aussi son option côté navigateur, qui mérite d’être citée. Le DNS over HTTPS, ou DoH, envoie vos résolutions à un résolveur par un canal chiffré plutôt que par le canal par défaut du réseau, et c’est souvent le premier réflexe de ceux qui découvrent les fuites DNS. Rien de tout cela ne remplace un test. Ce sont des leviers à essayer, puis à vérifier.

Vous n’avez pas à croire un argument marketing, et vous ne devriez pas avoir à le faire. Un test de fuite prend environ une minute. Ouvrez une page de test de fuite DNS et WebRTC, un vérificateur neutre comme browserleaks.com ou ipleak.net, et elle vous montrera quels résolveurs vos requêtes DNS atteignent et quelle adresse IP publique une page peut voir pour vous, WebRTC compris.

Faites-le une fois sur le réseau qui vous importe vraiment. Si le résolveur affiché est celui de votre fournisseur d’accès ou du réseau local, votre DNS fuit. Si l’adresse IP publique affichée est la vôtre, WebRTC ou la connexion l’expose. Activez votre outil et relancez le même contrôle pour voir si les chiffres changent.

La page /proof de TrickyBird vérifie autre chose, et il vaut mieux ne pas les confondre. Elle montre que l’adresse du site que vous ouvrez n’apparaît jamais dans votre barre d’adresse, dans le code source de la page, ni dans les en-têtes Referer et Origin que votre navigateur envoie. C’est un contrôle de fuite de domaine, pas un test DNS ou WebRTC : il n’affiche aucune adresse IP et ne vous dit pas si WebRTC expose la vôtre. Pour cela, utilisez l’une des pages de test de fuite ci-dessus et désactivez WebRTC dans votre navigateur. Un outil qui vaut la peine d’être utilisé est un outil qui résiste à quelqu’un qui ouvre les outils de développement et regarde. C’est le même critère qu’il vaut la peine d’appliquer à tout proxy web gratuit, le nôtre compris.

Poursuivez si vous voulez les bases sur lesquelles cet article s’appuie.

• Qu’est-ce qu’un proxy web ?
• Proxy web ou VPN
• Utiliser un proxy est-il légal ?
• Débloquer un site
• Notre politique de journalisation et de sécurité