DANE, valider l'intégrité des certifcats TLS

Analyse heuristique | Anti-relais | Botnet / Zombie | Bounce | DANE | Déni de service | DKIM | DMARC | DNSSEC | Faux-négatifs | Faux-positifs | Filtres bayésiens | FOVI - Arnaque au président | FQDN | Greylisting | Listes blanches | Listes noires / DNSBL | MTA / MDA | Opt-in | Opt-out | Phishing | Ransomware | Scam / Nigérian419 | SMTP | Spam | SPF | StartTLS | Teergrubing | Test de Turing | Virus / Malware

Définition de DANE : DANE (DNS-based Authentification of Named Entities) 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é.

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.

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

Articles en rapport avec dane :
- DANE pour sécuriser les échanges SMTP
- Comment optimiser la sécurité de sa messagerie électronique ?
- Comment fonctionne l'email ?
- La sécurité, notre priorité absolue
- Remise en question de la sécurité de la messagerie