Longtemps, l'adoption du chiffrement des requêtes DNS (DoH et DoT) a été présentée par l'industrie comme la solution définitive au problème de l'interception des routes utilisateur. La logique semblait inattaquable : si l'opérateur local ne voit plus le port UDP 53 brut, corréler le trafic sortant avec l'adresse spécifique d'une ressource devient mathématiquement impossible.
Cependant, l'analyse pratique des blocages récents et des fuites de données de ces derniers jours démontre le contraire : une confiance aveugle dans le DoH crée un faux sentiment de sécurité.
Les systèmes d'inspection en profondeur des paquets (DPI/TSPU) n'ont plus besoin de décrypter l'enveloppe chiffrée de la requête adressée au résolveur. Il leur suffit d'analyser la corrélation temporelle et la topologie des flux.
1. La mécanique de la corrélation temporelle : le DoH comme marqueur de début de session
La principale faiblesse architecturale du DNS chiffré réside dans son isolement par rapport au canal de transmission de données principal.
Lorsqu'un utilisateur tente d'ouvrir un nœud :
- Le client établit une session TLS vers un résolveur public (par exemple, Cloudflare, Google ou Quad9) et demande un enregistrement
A/AAAA. - Une fraction de seconde plus tard (delta de temps de réaction $\Delta t$, généralement entre 15 et 60 ms), une nouvelle connexion TCP/TLS est initiée depuis la même adresse IP d'abonné vers une adresse IP externe inconnue ou suspecte.
Pour les analyseurs statistiques de la passerelle de l'opérateur, ce délai $\Delta t$ constitue une signature pratiquement transparente. Même si le SNI est masqué et que la requête DNS est chiffrée, croiser le moment du pic de trafic sur le port du résolveur DoH avec l'heure du paquet SYN sortant vers un hôte externe permet de reconstituer l'accès avec une précision supérieure à 90 %. Vous fournissez vous-même au DPI le moment exact où il doit activer le module d'heuristique avancée sur le nœud de périphérie.
2. L'effondrement du concept des résolveurs centralisés
L'utilisation de services DoH publics engendre une seconde vulnérabilité fondamentale : la concentration des métadonnées entre les mains des listes réglementaires :
- Blocage par adresses IP des résolveurs eux-mêmes. L'opérateur n'a pas besoin d'analyser chaque paquet : il lui suffit d'ajouter les adresses des fournisseurs DNS indépendants populaires à ses listes de bridage. En conséquence, l'appareil de l'abonné bascule soit sur le DNS standard ouvert de l'opérateur (vulnérabilité de repli / fallback), soit commence à perdre des paquets lors de la résolution des noms.
- Fuites au niveau de la télémétrie des applications. La plupart des fuites de profils d'activité ne proviennent pas d'une interception sur le câble, mais du croisement de graphes de liens ouverts. Lorsque des millions de requêtes convergent vers un pool unique, les filtres des opérateurs séparent facilement le trafic de fond des services système des accès ciblés d'un utilisateur spécifique.
3. Les métadonnées de la couche transport : pourquoi une IP chiffrée en dit toujours trop
Même lorsque le nom d'hôte est totalement masqué (via ECH — Encrypted Client Hello), la passerelle de périphérie perçoit :
- Le système autonome de destination (ASN). Si le trafic est dirigé vers un hébergeur connu pour abriter des médias indépendants ou des proxys étrangers, ce fait est enregistré instantanément.
- La taille et la structure du certificat. La réponse du serveur lors de la phase de négociation TLS (TLS Handshake) est transmise par des paquets d'une longueur spécifique. La base de données d'empreintes des certificats populaires permet d'identifier la ressource même en l'absence de champ SNI ouvert dans l'en-tête de la requête.
Tenter de se protéger par des ajouts isolés, comme l'activation du DoH dans un navigateur sans isoler l'ensemble du flux réseau, revient à verrouiller une porte en verre.
4. Architecture d'une résolution de noms résiliente : le périmètre pratique
Pour que la résolution d'adresses ne se transforme pas en déclencheur pour les systèmes de filtrage, l'infrastructure doit répondre aux principes d'une stricte séparation des plans de contrôle :
- Un résolveur récursif local à l'intérieur du tunnel.
- Les requêtes DNS ne doivent jamais quitter les limites du canal chiffré personnel. La résolution des noms doit s'effectuer directement sur le nœud de sortie (exit node), sans solliciter de plateformes publiques tierces depuis votre adresse IP physique. Pour l'opérateur télécoms, la session doit apparaître comme un échange de données continu et monolithique avec une seule adresse de confiance.
- L'élimination des fuites de repli (DNS Leak).
- La pile réseau du système d'exploitation doit être configurée de manière stricte pour rejeter toute requête adressée aux ports 53 (UDP/TCP) qui contournerait le tunnel principal. En cas de brève instabilité du tunnel, l'interface réseau a l'obligation de bloquer le trafic (mécanisme Kill Switch) plutôt que d'envoyer une requête en clair vers la passerelle de l'opérateur.
- Des nœuds privés dédiés sans historique public.
- L'utilisation de votre propre serveur dédié exclut l'identification par le biais d'un pool de « voisins compromis ». Lorsque votre trafic DNS est cloisonné sur une instance isolée, les algorithmes de filtrage externes se trouvent privés de la base nécessaire au recoupement statistique.
La sécurité sur le réseau moderne repose sur l'élimination des corrélations. Tant que certains éléments de la pile réseau dialoguent avec l'extérieur de manière désordonnée, les systèmes de filtrage identifieront vos actions sans erreur. Une véritable confidentialité n'est atteinte que lorsque l'ensemble des données, y compris les métadonnées de service et les requêtes de noms, est encapsulé dans un périmètre unique, indissociable et homogène.