Le protocole DANE (DNS - based Authentication of Named Entities) pour la sécurisation de bout-en-bout

Aller directement à la présentation de DANE.

Sources :

• https://www.afnic.fr/data/divers/public/afnic-dossier-dnssec-2010-09.pdf
  
• https://www.afnic.fr/medias/documents/Dossiers_pour_breves_et_CP/dossier-thematique12_VF1.pdf

• Résolution DNS

Au niveau informatique, les serveurs sont identifiés sur le réseau à partir de leur adresse IP (suite de 4 nombres). L’utilisateur ou utilisatrice n’a pas vocation à mémoriser toutes ces adresses, mais plutôt des noms. La solution est apportée par le DNS qui est une sorte de botin où une adresse IP est rattachée à un nom de domaine¹⁾.

Traditionnellement, les DNS ne sont que des serveurs qui publient un tableau avec deux colonnes: des noms de domaine et des adresses IP. Pour des raisons de performance, il est très courant de mettre en place des serveurs intermédiaires qui gardent une copie (un cache) des données publiées par les serveurs primaires. Cependant, cela implique qu’un serveur DNS intermédiaire pourrait tout à fait publier des données erronées et donc diriger les utilisateurs vers un serveur malveillant.

Dans une infrastructure moderne, cette opération est sécurisée par le protocole DNSSEC qui inclut la signature cryptographique du serveur de nom dans l’enregistrement DNS. Concrètement, un condensat (ou hash) des champs de l’enregistrement est chiffré à l’aide de la clef privée du serveur de nom. Si le résolveur (serveur dont la première mission est d’identifier la machine sur laquelle est installé le nom de domaine recherché) veut contrôler l’authenticité ou l’intégrité des données transmises, il lui suffit de récupérer la clef publique dudit serveur de nom, de déchiffrer le condensat et de le comparer au condensat qu’il aura lui-même calculé à partir des informations fournies en clair. Ce protocole basé sur RSA neutralise notamment les attaques de Mallory (attaques de type Man-in-the-middle) en créant une chaîne de confiance depuis la racine du DNS. En effet, ce protocole prévoit que :

//"chaque zone parente, située au niveau supérieur de l’arborescence du DNS,// [garantit] //l’authenticité des clés de ses zones filles en les signant, les échanges de clés entre zones parentes et filles se faisant exclusivement par des canaux sécurisés."//((https://www.afnic.fr/data/divers/public/afnic-dossier-dnssec-2010-09.pdf))

C

‘est également une solution à une faille de la neutralité du net.

• Établissement de la connexion avec le serveur distant

L’adresse IP récupérée permet d’engager une communication avec le serveur (web, mail…) distant. Cette opération est sécurisée par le protocole TLS, basé sur des certificats à clef publique répondant à la norme X.509 et constituant le modèle PKIX. Ce type de certificat associe une clef publique à une identité particulière et est signé par une Autorité de Certification en qui l’utilisateurice a confiance²⁾. De la même manière que la résolution DNS, une chaîne de confiance arborescente est mise en place depuis un certificat racine identifiant une AC (Autorité de Certification) jusqu’au certificat concerné par le biais de chiffrement asymétrique interposé.

Actuellement, un titulaire de nom de domaine n’a pas la capacité de forcer la validation de la connexion à son domaine par un certificat particulier et délivré par une AC particulière. En effet, la multiplicité des AC, et leur pratique consistant à déléguer la génération de certificats à des succursales ou d’autres organisations, fragilisent toujours plus la sécurité du modèle PKIX. Il suffit d’une seule AC compromise (ou une de ses subordonnées) pour qu’un certificat reconnaissable par un navigateur puisse être généré pour un nom de domaine.

DANE concrétise l’idée de stocker dans le DNS les certificats x509 utilisés dans les transactions TLS, en s’appuyant sur le protocole DNSSEC pour garantir l’authenticité et l’intégrité de la résolution DNS. C’est donc une méthode de protection contre les attaques visant un nom de domaine particulier, notamment par empoisonnement du cache DNS. Si à ce stade, l’explication d’un tel protocole paraît inopportun dans la documentation d’un projet de déploiement d’un service mail, il faut savoir que DANE a également vocation à être mis en place pour l’échange de courriers électroniques, notamment avec le protocole SMTPS (chiffrement par le protocole TLS). Certains MTA, tels que Postfix, ont déjà développé des extensions pour permettre la compatibilité avec ce protocole.

La mise en vigueur du protocole DANE n’est pas encore une obligation, et pourtant celui-ci provoque déjà le débat, tant sur le plan sécuritaire que politque.

• Augmentation incontestable de la sécurité. Les deux opérations que sont la résolution DNS et la connexion au serveur distant pouvant être considérées comme sécurisées, le protocole DANE s’apparente à la clef de voûte de la sécurisation de bout-en-bout, et pallie à l’ultime faille d’une navigation web ou mail.
• Dans l’absolu, DANE est également une alternative aux AC, considérées par certain.es comme des

"//centres de concentration de pouvoir// [...] //qui vendent exclusivement du vent//"((http://shaarli.guiguishow.info/?M3y2yQ)).

Ils sont plus nombreux et une liste plus importante peut être faite en combinant cette source ci et cette source là.

• Remise en cause à plus bas niveau du protocole DNSSEC:
  • Contrôle gouvernemental à travers la chaîne de confiance découlant du ccTLD
  • Génération initiale de clefs de 1024 bits par défaut réputée trop fragile ³⁾
  • Coût en termes de stockage, de temps de calcul ou encore de temps de connexion d’ajouter un tel champ à l’enregistrement DNS
  • …

• Temps de connexion pour le protocole DANE
• L’évincement des AC n’est qu’une apparence, DNSSEC reprenant leur rôle
• Faible tolérance aux enregistrements DNS non-standard. Peut-être en inadéquation avec le web ouvert?