DANE

Définition : Qu’est-ce que le DANE ?

Le DANE (DNS-Based Authentication of Named Entities) est un protocole de sécurité qui utilise le système DNS pour sécuriser les communications en ligne. Il permet de garantir l’authenticité et l’intégrité des connexions sécurisées telles que les connexions SSL/TLS. DANE est un protocole standardisé qui vise à valider le certificat utilisé lors d’une connexion sécurisée par TLS. La machine initiant une connexion va pouvoir récupérer l’empreinte du certificat de son correspondant via un enregistrement DNS afin de confirmer son intégrité.

Pourquoi sécuriser vos serveurs SMTP avec DANE ?

Sécuriser les serveurs SMTP avec DANE permet de garantir que les communications entre les serveurs de messagerie sont authentiques et confidentielles. Cela empêche les attaques telles que les interceptions de messages et les falsifications de l’identité des serveurs.

Comment utilise-t-on le protocole DANE ?

Le protocole DANE utilise des enregistrements DNS spécifiques pour stocker des informations sur les clés publiques des serveurs de messagerie. Les serveurs de messagerie peuvent utiliser ces enregistrements pour vérifier que la clé publique présentée par le serveur de messagerie distant est authentique et n’a pas été falsifiée. Pour utiliser le protocole DANE, il est nécessaire de disposer d’un fournisseur de DNS compatible avec DANE et d’un client de messagerie qui prend en charge ce protocole.

La mise en place de DANE implique donc de générer et de maintenir à jour l’empreinte de la clé du certificat. Elle devra être accessible par l’intermédiaire d’un enregistrement TLSA associé au nom d’hôte de la machine concernée. Le serveur DNS gérant cet enregistrement devra nécessairement utiliser DNSSEC afin d’assurer la validité de la transaction et des données. DANE est compatible avec toutes les communications utilisant TLS, mais se trouve principalement utilisé pour sécuriser les échanges entre serveurs SMTP.

Exemples

Voici un exemple concret de fonctionnement de DANE lors de l’envoi d’un email de « from@exp.fr » vers « to@dest.fr » :

– Le serveur exp.fr envoie une requête DNS pour connaître les MX de dest.fr :
# dig MX dest.fr
dest.fr. 3600 IN MX 10 mail.dest.fr

– Le serveur émetteur cherche si le serveur destinataire a une entrée TLSA. Pour cela, il génère une requête qui contient le numéro de port visé (25), le protocole (TCP) ainsi que le nom d’hôte :
# dig TLSA _25._tcp.mail.dest.fr
_25._tcp.mail.dest.fr. IN TLSA 3 1 1 42DDBACBE48CBB37…3D D53D2CB4

– Il se connecte au serveur de messagerie mail.dest.fr qui lui transmet sa clé publique (présente dans le certificat) lors de la poignée de main TLS. Le serveur émetteur est alors capable de comparer l’empreinte et la clé publique afin d’en vérifier son intégrité. Cependant, si l’enregistrement TLSA n’est pas signé par DNSSEC, si un élément est manquant ou incorrectement renseigné, la connexion bascule en TLS classique.

Alternative à DANE: MTA-STS

MTA-STS (Mail Transfer Agent – Strict Transport Security) est un mécanisme, initié et poussé par Google, qui permet, par l’intermédiaire d’une politique accessible en HTTPS, d’annoncer aux serveurs émetteurs si un serveur destinataire impose le chiffrement TLS. Il utilise une politique accessible par l’intermédiaire d’un serveur Web qui indique les serveurs de messagerie du destinataire. Ce document intègre un identifiant qui doit être mis à jour en cas de changement de politique. Contrairement à DANE, MTA-STS agit au niveau du domaine plutôt qu’au niveau du serveur, il est purement destiné à la messagerie.

MTA-STS est considéré comme moins pertinent que DANE, principalement pour deux raisons :

– Le domaine doit intégrer un serveur Web, qu’il faut lui-même entretenir et sécuriser.

– La validation des certificats repose sur les autorités de certification connues de l’émetteur, là où DANE valide le certificat par sa cohérence avec l’empreinte, ce qui prend en compte notamment les certificats autosignés ou issus d’autorités de certification inconnues de l’émetteur.

Heureusement, les deux techniques n’interfèrent pas entre elles et sont pleinement compatibles. L’idéal est donc d’exploiter les deux systèmes afin que les serveurs émetteurs aient le choix du protocole à utiliser.