DANE, valider l'intégrité des certifcats TLS
Définition de 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.
Applications
Tous les serveurs Altospam sont paramétrés pour utiliser DANE, ainsi c’est l’ensemble de nos clients qui bénéficient de la protection appliquée à nos équipements, sans qu’aucune modification ne soit nécessaire, quel que soit le domaine destinataire. Cependant, pour que cela soit effectivement opérationnel, il est nécessaire que le domaine du client soit sécurisé par DNSSEC.
L’email est le principal vecteur d’une cyberattaque
De nouvelles attaques de plus en plus sophistiquées sont lancées dans le monde tous les jours. Notre solution détecte et neutralise les menaces de phishing, spear-phishing, malware, ransomware et spam en temps réel.
Informations complémentaires
- RFC 7672 définissant DANE
- Dossier de l’AFNIC sur DANE – Article sur le fonctionnement du Greylisting et son intégration dans ALTOSPAM