Changer de DNS, chiffrer les requêtes, masquer les destinations derrière un VPN… Les solutions ne manquent pas pour réduire l’exposition de notre navigation. Leur efficacité se joue pourtant dans les détails, entre ce qu’elles protègent réellement, ce qu’elles laissent passer et à quel moment.
Ouvrir un site web commence souvent avant même la connexion au serveur qui l’héberge. Pour savoir vers quelle adresse acheminer le trafic, votre appareil doit d’abord résoudre son nom de domaine. Cette étape discrète passe par le DNS et produit des informations qui intéressent directement notre vie privée. HTTPS protège désormais l’essentiel du contenu échangé avec les sites, mais les requêtes DNS peuvent encore révéler les services que nous cherchons à joindre. On peut alors être tenté d’agir sur cette résolution pour mieux protéger sa navigation. Mais entre le choix du résolveur et la manière dont les requêtes lui sont envoyées, il s’agit souvent moins de les rendre invisibles que de décider qui pourra encore les lire.
DNS et vie privée, bien plus qu’un annuaire technique
Lorsque vous saisissez une adresse dans votre navigateur ou qu’une application contacte un service en ligne, votre appareil a besoin de convertir son nom de domaine en adresse IP, utilisée par le réseau pour acheminer les communications jusqu’à leur destination.
Ce travail repose sur le DNS, pour Domain Name System, un annuaire distribué qui permet par exemple d’associer clubic.com à l’adresse d’un serveur capable de répondre à la requête. Votre appareil ne parcourt pas lui-même cet annuaire. Il interroge généralement un résolveur DNS, chargé d’effectuer les recherches nécessaires puis de lui retourner la réponse.
À la maison, ce résolveur est souvent fourni par le FAI. Il n’accède ni au contenu protégé par HTTPS ni à l’URL complète de la page consultée. En revanche, il voit les noms de domaine et sous-domaines que votre appareil lui demande de résoudre, et à quel moment.
Ces informations ne constituent pas une copie exacte de votre historique de navigation. Une seule page peut déclencher des requêtes vers de nombreux domaines tiers pour charger des images, des scripts ou d’autres ressources, tandis que le navigateur peut lui-même résoudre à l’avance le domaine de certains liens avant que vous ne cliquiez dessus. Une messagerie ou un service de synchronisation peut aussi automatiquement solliciter le DNS en arrière-plan, sans intervention de votre part. À l’inverse, la consultation d’un site peut ne provoquer aucune nouvelle requête DNS si l’adresse correspondante est déjà conservée dans le cache du navigateur ou du système.
Un résolveur n’observe donc pas toutes vos visites, et toutes les requêtes qu’il reçoit ne correspondent pas à une action explicite de votre part. Sur la durée, elles sont pourtant très révélatrices. La répétition de requêtes vers des domaines liés à une banque, un média, une messagerie, une plateforme vidéo ou un service de santé permet déjà de reconstituer une partie des usages d’une connexion, même sans avoir accès au contenu des échanges.
Ce rôle d’intermédiaire donne aussi au résolveur un pouvoir sur la réponse qu’il renvoie. Des services spécialisés peuvent ainsi refuser de résoudre des domaines associés au phishing ou aux logiciels malveillants, tandis que les FAI peuvent employer le DNS pour appliquer des décisions de blocage ciblant, par exemple, des sites de streaming ou de téléchargement illégal.
Changer de DNS revient aussi à changer d’intermédiaire
Rien n’oblige toutefois à s’en remettre au résolveur de son opérateur. On peut confier cette tâche à un service tiers que l’on juge plus intéressant pour ses engagements en matière de confidentialité, comme Cloudflare, ses protections contre les domaines malveillants, comme Quad9 (également réputé pour son approche respectueuse de la vie privée), ou ses performances, comme le DNS public de Google.
Changer de résolveur ne fait cependant pas disparaître l’intermédiaire chargé de traiter les requêtes. Même Quad9, qui affirme ne pas enregistrer les adresses IP de ses utilisateurs, doit brièvement conserver en mémoire vive l’adresse d’où provient une requête, le temps de la traiter et de renvoyer la réponse. Elle est ensuite supprimée sans être enregistrée.
Le choix d’un DNS public peut donc réduire les données conservées ou modifier l’usage qui en est fait, mais il déplace surtout la confiance vers un nouvel acteur. Et tant que les requêtes circulent en clair, le FAI peut toujours les lire sur son trajet, même s’il n’est plus chargé de les résoudre.
DoH et DoT chiffrent le trajet, pas la destination
Pour empêcher cette lecture pendant le transport, DNS over HTTPS (DoH) et DNS over TLS (DoT) chiffrent les échanges entre votre appareil et le résolveur choisi. Un FAI, un opérateur de Wi-Fi public ou un autre intermédiaire réseau ne peut alors plus observer les domaines sollicités, ni altérer les réponses au passage.
Alors, résolveur très protecteur de la vie privée + requêtes chiffrées jusqu’à lui = problème réglé ? Pas tout à fait. Le résolveur doit toujours accéder au nom de domaine demandé pour pouvoir le traduire en adresse IP et renvoyer la réponse. Même s’il n’en conserve aucune trace durable, il traite forcément cette information le temps de la résolution.
Il faut aussi savoir que le nom du site peut encore fuiter au moment d’établir la connexion HTTPS, dans les premières informations échangées avec le serveur, problème auquel doit répondre Encrypted Client Hello (ECH), chargé de chiffrer cette partie de la négociation TLS pour empêcher qu’elle soit lue par le FAI ou d’autres intermédiaires réseau.
Reste que même avec DoH ou DoT et ECH, le FAI n’est toujours pas aveugle. Il connaît encore les adresses IP des serveurs auxquels vous vous connectez. Elles ne permettent pas systématiquement d’identifier un site avec précision, plusieurs services pouvant partager la même infrastructure, mais elles donnent encore des indications sur la destination contactée.
Le VPN redistribue encore les cartes, sans supprimer les intermédiaires
Vous le voyez venir : pour masquer aussi ces destinations au FAI, il faut faire passer le trafic par un autre intermédiaire. C’est ce que fait un VPN. Son tunnel chiffré protège les requêtes DNS qui y transitent, mais aussi les connexions établies ensuite avec les services distants. Le FAI ne voit alors plus les serveurs finaux contactés, seulement une communication chiffrée entre votre appareil et le serveur VPN.
La plupart des applications VPN font également passer les requêtes DNS dans ce tunnel et les dirigent vers leurs propres résolveurs, entre autres pour éviter les fuites DNS. Le fournisseur VPN occupe alors une position particulièrement privilégiée : il contrôle le point de sortie du tunnel et peut, dans le même temps, prendre en charge la résolution des domaines. On retrouve donc le problème de départ, déplacé une nouvelle fois vers un autre acteur.
Il est possible de dissocier davantage ces rôles en utilisant, à travers le VPN, un résolveur tiers accessible en DoH. Le fournisseur DNS reçoit alors la requête depuis l’adresse IP de sortie du VPN plutôt que depuis celle de l’abonné, tandis que le VPN transporte une requête chiffrée qu’il ne peut pas lire directement. La séparation reste toutefois imparfaite : le VPN conserve de la visibilité sur les connexions qui quittent ensuite son serveur vers Internet.
D’autres protocoles poussent cette séparation plus loin. Oblivious DNS over HTTPS (ODoH), encore expérimental mais déjà pris en charge par des infrastructures comme celle de Cloudflare, intercale un relais entre l’utilisateur et le résolveur. Le relais connaît l’adresse IP de l’utilisateur mais ne peut pas lire la requête chiffrée, tandis que le résolveur peut traiter le domaine demandé sans connaître directement l’adresse IP d’origine. Aucun des deux ne dispose donc seul des deux informations.
À chaque étape, la confidentialité progresse moins par disparition des intermédiaires que par séparation de ce qu’ils peuvent observer. Changer de résolveur déplace la confiance, DoH et DoT protègent les requêtes pendant leur trajet, ECH masque le nom du site dans les premiers échanges HTTPS, le VPN cache les destinations finales au FAI et ODoH sépare l’origine d’une requête DNS de son contenu. Libre à chacun, ensuite, de faire sa tambouille selon le niveau de confidentialité recherché et les intermédiaires auxquels il accepte encore de faire confiance.
