DNS chiffré : DoH et DoT

La leçon précédente décrivait une recherche DNS classique comme une carte postale : lisible par quiconque la manipule en chemin. Deux normes de l’IETF existent pour mettre cette carte postale sous enveloppe : DNS over TLS (DoT, RFC 7858) et DNS over HTTPS (DoH, RFC 8484). Les deux chiffrent la même recherche ; elles diffèrent surtout par la façon dont elles la transportent.

DNS over TLS

La RFC 7858 énonce directement son objectif : « le chiffrement fourni par TLS élimine les possibilités d’écoute clandestine et de falsification en chemin des requêtes DNS », répondant au fait que « la quasi-totalité des requêtes DNS sont envoyées sans chiffrement, ce qui les rend vulnérables à l’écoute clandestine par un attaquant ». DoT utilise son propre port dédié, le 853, plutôt que le port habituel 53. La RFC explique pourquoi : « cette recommandation contre l’utilisation du port 53 pour DNS over TLS vise à éviter de compliquer le choix d’utiliser ou non TLS, et à réduire le risque d’attaques par rétrogradation. »

DNS over HTTPS

La RFC 8484 emprunte une voie différente : « chaque paire requête-réponse DNS est transposée dans un échange HTTP », transporté sur le même port 443 que le trafic HTTPS ordinaire. La RFC note un avantage secondaire : « le port par défaut 443 de HTTPS et la possibilité de mélanger le trafic DoH avec d’autres trafics HTTPS sur la même connexion peuvent dissuader des dispositifs en chemin non privilégiés d’interférer avec les opérations DNS », car une recherche est plus difficile à isoler et à bloquer quand elle ressemble à n’importe quelle autre requête web.

Ce que le chiffrement cache, et ce qu’il ne cache toujours pas

Les deux normes empêchent un opérateur réseau ou un espion Wi-Fi de lire vos recherches en transit. Aucune ne les cache du résolveur auquel vous les avez envoyées. La RFC 8484 précise explicitement que DoH ne change rien à ce que le serveur lui-même peut voir : elle note que « divers transports des requêtes et réponses DNS fournissent bel et bien des données pouvant être utilisées pour corréler les requêtes », et que des mécanismes web ordinaires tels que les adresses IP du client, les cookies et les informations de session TLS signifient que « DoH n’est pas connu pour introduire de nouvelles préoccupations au-delà de celles associées à HTTPS » côté serveur. La RFC 7858 note de même que DoT « ne traite pas les autres problèmes de sécurité du DNS » et que « même avec des messages chiffrés, une partie bien positionnée peut être capable de glaner certains détails à partir d’une analyse des horodatages et des tailles des messages ». En bref : le DNS chiffré ramène qui voit vos recherches à l’opérateur du résolveur que vous avez choisi, il ne supprime pas la visibilité pour autant.

Il existe un second angle mort à connaître. Chiffrer la recherche DNS ne cache pas en soi le site auquel vous vous connectez ensuite : la négociation TLS qui suit inclut normalement le nom d’hôte en clair. Comme l’explique Cloudflare à propos de l’Indication du nom de serveur (SNI), « le SNI inclut le nom d’hôte dans le message Client Hello, c’est-à-dire la toute première étape d’une négociation TLS » — envoyé avant que le chiffrement ne soit établi. Une extension appelée SNI chiffré (ESNI), explique la même source, « s’ajoute à l’extension SNI en chiffrant la partie SNI du Client Hello », ce qui « empêche quiconque espionne entre le client et le serveur de voir quel certificat le client demande ». La prise en charge du masquage du SNI dépend toujours de l’accord du navigateur et du site, et ce n’est pas encore ainsi que fonctionne chaque connexion.

Comment macOS le prend en charge

Apple documente une configuration des réglages DNS pour Mac, iPhone et iPad qui fait exactement cela : elle permet à un appareil de « faire transiter les requêtes DNS d’un appareil par un serveur DNS chiffré en utilisant DNS over HTTPS ou DNS over TLS ». Elle est livrée sous forme de profil de configuration, qui peut restreindre le résolveur chiffré à des domaines spécifiques via des « domaines de correspondance supplémentaires », ou ne s’appliquer que sur certains réseaux à l’aide de « règles à la demande » pouvant correspondre à des éléments comme le SSID du réseau.