Menu Fermer

DNSSEC, DNS Over TLS ou HTTPS (DoT et DoH) et DNSCrypt : les différences

En cherchant à sécuriser vos connexions internet, vous êtes tombés sur plusieurs termes concernant la résolution DNS.
Ainsi, on trouve souvent les mentions DNSCrypt, DNSSEC, DNS Over TLS ou HTTPS.
Mais quelles sont les différences ?

Cet article vous dit tout autour du chiffrement DNS et en quoi ces protocoles aident à sécuriser vos DNS.

DNSSEC, DNS Over TLS ou HTTPS (DoT et DoH) et DNSCrypt : les différences

DNS et les problèmes de sécurité: pas de chiffrement et authentification

Pour les bases concernant DNS, lisez cet article complet :

Le protocole DNS est un ancien protocole qui n’a que très peu évolué.
Par défaut, le protocole DNS utilise le port 53 en UDP car ce protocole est plus rapide que le TCP (mais il est possible d’utiliser des requêtes DNS en TCP).
Dans les deux, les paquets qui transitent sont en clair et donc le protocole est non chiffré.
Ci-dessous, on récupère très facilement les requêtes DNS depuis un ordinateur attaquant.
Cela permet à un attaquant de récupérer les sites visités ou à des entités d’espionner massivement les internautes.
Un service VPN qui récupère le trafic DNS peut donc très bien vous suivre.

Pister le Trafic DNS

Ce qu’il faut retenir, c’est que les requêtes DNS posent des problèmes de sécurité :

  • Les résolutions DNS ne sont pas chiffrés et passent en clair. Cela pose donc des problèmes de confidentialité. On peut en partie savoir ce que vous faites sur la toile.
  • Elles ne sont pas authentifiées. Lorsque un appareil reçoit la réponse DNS, il n’a que très peu de moyen de savoir qui a répondu. Ainsi un attaquant peut les falsifier (cache poisoning) et attaque man-in-the-middle (MITM).
  • Pose des problèmes de confidentialité. Un attaquant peut obtenir les informations suivantes :
    • Le nom de domaine que vous demandez (example.com)
    • Combien de demandes vous faites et quantité de données transférées
    • Qui répond à votre demande (quel serveur DNS)
    • Quelle réponse le serveur DNS a renvoyé
    • Qui a reçu la réponse (vous)

Sécuriser le protocole DNS

Pour tenter de résoudre ces problèmes de sécurité, il existe des protocole DNS expérimental.
Voici une liste pour déjà avoir un aperçu des différences :

  • DNSCrypt, ce dernier fonctionne sur le port 443 en TCP ou UDP.
  • DNS over HTTPs qui utilisent le protocole HTTPs pour chiffrer les requêtes
  • DNS over TLS un protocole de chiffrent DNS sur le port 853. (RFC-7858). Pour ce dernier, lire la page: Protocole TLS : fonctionnement et différences entre les versions
  • DNS over Datagram Transport Layer Security (DTLS) sur le port 853 aussi mais avec UDP. (RFC-8094)
  • DNSCurve
  • DNS-over-HTTP (DOH) : DNS over HTTP/2.
  • DNS-over-QUIC
  • DNS-over-DTLS voir : RFC8094

Pour que cela fonctionne, il faut donc que le serveur DNS utilisé supporte ces protocoles.
Or actuellement, tous ne supportent pas le chiffrent.

Comparatif des serveurs de noms (DNS)
DNSDNSSECDoTDoHDNSCrypt
CleanBrowsing
Cloudflare
Google
Quad9
UncesoredDNS
SafeDNS
OpenDNS
Comparatif support DNSSEC, DoT, DoH, DNSCrypt par services DNS


Vous trouverez aussi un comparatif sur le site :

Bien entendu, il faut bien choisir le serveur DNS, si le but est d’éviter le pistage par votre fournisseur d’accès, il ne faut pas prendre les DNS de Google qui font pas mieux.

DNSCrypt, DNSSEC, DNS Over TLS ou HTTPS : les différences

Le but de ces protocoles est donc :

  • Protéger contre le piratage et l’usurpation DNS
  • Protéger contre les attaque man in the middle

DNSSEC

DNSSEC (Domain Name System Security Extensions) est une extension DNS qui permet à un client de valider la réponse DNS sur les domaines et TLD pris en charge.

Les résolveurs vérifient la signature numérique des réponses DNS pour vérifier que les données correspondent à ce que le propriétaire de la zone a initialement configuré.
Cela repose sur l’utilisation d’un chiffrement asymétrique et utilise donc un schéma utilisant deux clés: une clé privée et une clé publique.
Le but de DNSSEC est de protéger contre l’empoisonnement de cache DNS (DNS cache poisoning)

Cela dit, DNSSEC n’est pas parfait. Il ne peut pas intercepter le trafic entrant et ne protège donc pas directement contre les attaques par déni de service (DoS).
Il ne garantit pas la confidentialité des données, il est donc possible pour un tiers de consulter l’historique DNS d’un utilisateur.

DNS Over TLS (DoT) et DNS Over HTTPS (DoH)

DoH et DoT établissent un tunnel sécurisé entre le client et le serveur DNS.
Ils garantissent qu’un client reçoit des informations d’adresse IP précises, éliminant ainsi les opportunités pour les tiers de voir à quels sites Web un utilisateur tente d’accéder.

Bien que ses capacités soient supérieures à DNSSEC, DoH et DoT n’élimine pas entièrement les vulnérabilités liées à la confidentialité.
En effet, il est toujours possible pour un tiers d’observer une demande de connexion initiale faite avant le chiffrement (Server Name IndicationSNI).

Pour assurer une confidentialité DNS maximale, DoH et DoT fonctionnent mieux en tandem avec DNSSEC et d’autres mesures de sécurité qui valident les autorités de certification SSL (CA) utilisées pour les connexions au site.

Différences entre DoT et DoH

DNS Over TLS comme son nom l’indique s’appuie sur le protocole TLS (Transport Layer Security).
De ce fait DoT fonctionne avec le protocole TCP avec comme port par défaut 853.
Cela rend donc ce dernier assez facile à bloquer puisqu’il suffit d’interdire la connexion vers ce port sortant.
Bien entendu, on peut utiliser un serveur DoT sur un autre port.
Enfin on peut plus facilement écouter le trafic sur ce port dédié.

DNS Over HTTPs (DoH) se base donc sur le chiffrement HTTPS qui fonctionnent en standard sur le port 443.
Cela rend donc le blocage de ce dernier plus difficile puisqu’il se mélange avec le trafic HTTPS classique.
Sachant qu’en plus, on peut le configurer sur le navigateur WEB, cela permet de contourner la configuration du poste.

DNS over TLSDNS over HTTPS
RFC 8484 RFC 8310 et RFC 7858
DNS over TLS utilise le protocole TCPDNS over HTTPS utilise le protocole HTTP/2 et HTTPS
utilise le port 853Utilise le port standard HTTPS soit donc 443
DNS over TLS est une bonne option lorsque l’utilisateur ne souhaite pas traiter avec les clients, qui sont fournis par les référents / redirecteurs DNS.DNS over HTTPS est la bonne solution lorsque d’autres ports sont bloqués.
Différences entre DoT et DoH

DNSCrypt

DNSCrypt est une méthode d’authentification des communications entre un client DNS et un résolveur DNS.
Il chiffre à la fois la question et la réponse, les rendant invisibles aux espions. Il signe également efficacement le message, vous savez donc que le serveur que vous avez contacté a vraiment envoyé la réponse et non un imposteur.
C’est une spécification ouverte mais elle n’a pas été normalisée par l’IETF.

  • Il empêche l’usurpation DNS
  • Comme DNSSEC, Il utilise des signatures cryptographiques pour vérifier que les réponses proviennent du résolveur DNS choisi et n’ont pas été falsifiées (les messages sont toujours envoyés via UDP).
  • Il chiffre la communication DNS.
  • Ne peut être la cible d’outil MiTM
  • DNSCrypt et DoH peuvent également être servis simultanément sur le même port

Dans Windows, on peut utiliser le client SimpleDNS ou YogaDNS qui sont compatibles DNSCrypt.

Résumé et comparatifs DNS

Protocoles DNSPort
par défaut
ChiffrementAuthentificationConfidentialité
DNSSEC443
DNS Over TLS (DoT)853
DNS Over HTTPS (DoH)443
DNSCrypt443
Comparatif des protocoles DNS

Fuite du SNI dans DoH : les solutions EHC, ESNI

DoH ne règle pas tous les problèmes de sécurité.
En effet, il faut savoir que lors de la négociation TLS, il est possible que des paramètres soient négociés en clair entre le client et le serveur.
Notamment, on y trouve l’indication du nom du serveur ou Server Name Indication (SNI).
L’extension SNI est utilisée par le client pour indiquer au serveur quel site web il veut atteindre. 
Cela permet de pister les internautes, voire des attaques de l’homme du milieu.

Encrypted SNI (ESNI) a tenté de résoudre cela en chiffrant cette négociation TLS mais son déploiement a posé trop de problème et a été abandé.
Une nouvelle spécification ECH (Encrypted Client Hello) tente de surmonter cela.
Pour le moment, elle n’est pas encore utilisée à grande échelle.

Liens