Oblivious DoH (ODoH) et VPN : les limites du DNS à deux sauts

Lorsque les protocoles de chiffrement du système de noms de domaine, tels que DNS-over-HTTPS (DoH, RFC 8484) et DNS-over-TLS (DoT, RFC 7858), ont été adoptés, l'objectif premier était de sécuriser la liaison entre le terminal et le résolveur récursif. Ces normes ont permis d'empêcher efficacement les fournisseurs d'accès à Internet et les intermédiaires sur les réseaux Wi-Fi publics de lire les requêtes DNS transmises en clair sur le port UDP 53.

Cependant, le DoH classique a introduit un paradoxe de confidentialité notable : il a concentré les métadonnées de navigation entre les mains d'un nombre restreint de résolveurs centralisés. Lors de l'envoi d'une requête vers un résolveur public majeur (comme Cloudflare, Google Public DNS ou Quad9), cet acteur unique observe simultanément deux éléments critiques :

1. L'identité de l'émetteur : l'adresse IP publique de votre machine.
2. L'objet de la demande : le nom de domaine exact que vous vous apprêtez à visiter.

Cette centralisation a incité l'Internet Engineering Task Force (IETF) à concevoir et normaliser Oblivious DNS over HTTPS (ODoH, RFC 9230) ainsi que le modèle architectural d'Oblivious HTTP (OHTTP, RFC 9458). Bien qu'ODoH apporte une séparation cryptographique ingénieuse entre l'adresse IP et le contenu interrogé, une confusion subsiste chez certains utilisateurs qui imaginent qu'ODoH élimine le besoin d'un réseau privé virtuel (VPN).

L'analyse de la mécanique réseau d'ODoH démontre pourquoi ce système à deux sauts résout l'enjeu au niveau du résolveur, tout en laissant les flux de données réels exposés en l'absence d'un tunnel de couche réseau.

Le fonctionnement architectural d'Oblivious DoH

Le postulat fondateur d'Oblivious DoH est clair : aucune entité unique ne doit connaître simultanément l'adresse IP de l'utilisateur et le domaine interrogé.

Pour briser la corrélation entre identité et charge utile, la norme RFC 9230 instaure un échange articulé autour de trois intervenants : le Client, le Relais (Relay) et le Résolveur cible (Target) :

[ Équipement Client ]
          |
          | 1. Envoi de la requête chiffrée en HPKE
          v
[ Relais ODoH Relay ] (Connaît l'IP cliente, ne peut pas lire la requête)
          |
          | 2. Suppression de l'IP cliente, transfert du cryptogramme
          v
[ Résolveur cible ODoH Target ] (Déchiffre la requête, voit le domaine, ignore l'IP cliente)
          |
          | 3. Résolution DNS, chiffrement de la réponse
          +-----> Retour via le Relais -----> Équipement Client

1. Le chiffrement hybride à clé publique (HPKE)

Avant de transmettre sa requête, le client récupère la configuration de clé publique du serveur cible (odohconfig) par le biais d'un canal sécurisé HTTPS.

À l'aide du chiffrement hybride HPKE (RFC 9180), le terminal encapsule le paquet binaire DNS avec une clé symétrique temporaire dérivée de la clé publique du Target. Ce paquet scellé est ensuite expédié vers le Relais.

2. Le rôle du relais aveugle (Relay)

Le Relais réceptionne l'enveloppe chiffrée par une session HTTPS ordinaire. Ne disposant pas de la clé privée du Target, il est dans l'incapacité matérielle d'en déchiffrer le contenu.

Le Relais agit comme un intermédiaire neutre : il efface l'adresse IP source du client dans les entêtes de transport, y substitue sa propre adresse IP, et achemine le bloc de données opaque vers le résolveur Target.

3. Traitement par le résolveur cible (Target)

Le résolveur Target reçoit le paquet émis depuis l'adresse IP du Relais et ignore tout de l'émetteur d'origine.

À l'aide de sa clé privée, il déchiffre la requête, exécute la résolution DNS auprès des serveurs d'autorité, chiffre la réponse obtenue avec le contexte symétrique HPKE établi, puis renvoie le paquet au Relais qui le réexpédie au client.

Grâce à cette séparation, le Relais sait qui vous êtes, mais ignore ce que vous cherchez ; le Target sait ce que vous cherchez, mais ignore qui vous êtes.

Les angles morts structurels d'Oblivious DoH

Bien qu'ODoH représente une innovation remarquable pour la résolution de noms, l'observation globale des connexions réseau fait ressortir des limites évidentes :

1. La connexion web ultérieure expose l'adresse IP

La résolution DNS ne constitue qu'un préalable. Dès que le système d'exploitation obtient l'adresse IP du serveur distant via ODoH, il initialise la connexion TCP ou QUIC directe avec le site web ciblé.

À cet instant précis, des paquets IP conventionnels contenant votre adresse IP publique réelle sont expédiés en clair vers le serveur hôte. En outre, si la plate-forme web distante n'applique pas l'extension Encrypted Client Hello (ECH), le nom d'hôte est transmis en clair dans l'entête SNI sur le réseau local.

ODoH empêche le résolveur DNS de dresser un profil de navigation, mais le site web final, les régies publicitaires et votre opérateur continuent d'observer l'intégralité de vos paquets de données.

2. Le postulat de non-collusion entre acteurs

La robustesse de la RFC 9230 repose sur l'hypothèse stricte que les opérateurs du Relais et du Target n'ont aucune entente préalable.

Si ces deux serveurs appartiennent au même groupe d'infrastructure ou corrèlent leurs journaux de flux réseau, la concordance des horodatages et des tailles de paquets permet d'annihiler la séparation des identités.

3. Allongement de la latence et routage géographique sous-optimal

L'acheminement des requêtes au travers de deux entités réseau distinctes augmente inévitablement le temps d'aller-retour (RTT). Une requête DoH classique s'effectue en un seul saut, tandis qu'ODoH exige deux transits successifs via des systèmes autonomes (AS) séparés.

Par ailleurs, comme le Target ne voit que l'IP du Relais, il ne peut pas utiliser le mécanisme EDNS Client Subnet (ECS) sans compromettre la vie privée. Les serveurs d'autorité peuvent donc retourner des adresses de serveurs CDN optimisées pour le centre de données du Relais plutôt que pour la zone géographique réelle de l'utilisateur, ce qui pénalise les débits de téléchargement et de streaming.

Comparatif technique : protocoles DNS et encapsulation de niveau 3

Les différences fondamentales entre l'approche applicative (Layer 7) et l'encapsulation réseau (Layer 3) sont résumées ci-dessous :

Pourquoi la confidentialité globale exige un tunnel de niveau 3

Tenter de sécuriser ses échanges en empilant des protocoles applicatifs cloisonnés (DoH, ODoH, proxies de navigateurs) laisse subsister des fuites structurelles. Les paquets réseau annexes — annonces de découverte locale, trames ICMP, requêtes des processus système d'arrière-plan — continuent de circuler sans protection sur le réseau physique.

Un réseau privé virtuel de niveau 3 aborde la question de la confidentialité à la racine :

1. Masquage systématique des adresses : Chaque paquet émis — qu'il s'agisse d'un appel DNS, d'une synchronisation en tâche de fond ou d'un transfert de fichiers — est encapsulé dans une enveloppe chiffrée uniforme dirigée uniquement vers le concentrateur VPN.
2. Résolution DNS locale sur le point de sortie : Avec une architecture comme RiceGuard, la résolution récursive s'opère directement sur l'interface de bouclage interne de la passerelle VPN. Aucun paquet DNS ne transite par des relais tiers. La résolution émane de l'adresse IP partagée du serveur VPN, réalisant le découplage d'identité d'ODoH sans ajouter de latence.
3. Couverture globale de la machine : Alors qu'ODoH nécessite une prise en charge au sein de chaque logiciel, le tunnel de niveau 3 s'intègre au noyau du système d'exploitation via une interface virtuelle (tun/tap), protégeant de manière transparente tous les navigateurs, commandes terminales et applications mobiles.

L'approche architecturale de VPNRice

Dans l'ingénierie des réseaux, les protocoles tels qu'ODoH constituent d'excellentes avancées théoriques, mais la sécurité concrète repose sur le confinement systématique de l'ensemble de la pile réseau.

VPNRice applique cette protection rigoureuse :

Sur le segment physique, le protocole RiceGuard encapsule l'intégralité du trafic à l'aide de l'algorithme ChaCha20-Poly1305 vers des nœuds d'infrastructure optimisés. Les observateurs locaux ne voient qu'un flux chiffré uniforme de paquets UDP.

Toutes les requêtes de noms de domaine sont interceptées et résolues par l'infrastructure interne sans journalisation de VPNRice. En masquant votre adresse IP tant pour la phase de résolution DNS que pour les sessions web qui en découlent, VPNRice offre la dissociation d'identité visée par ODoH à l'ensemble de vos communications en ligne. Télécharger VPNRice.