Vérificateur d'enregistrements DANE/TLSA
Interroge plusieurs résolveurs DNS publics sur les enregistrements TLSA publiés par les serveurs de messagerie (hôtes MX) d'un domaine afin de vérifier si DANE est configuré.
Astuces
- Les enregistrements TLSA ne se trouvent pas sous le nom de domaine ordinaire, mais sous un nom spécial, `_25._tcp.{hôte MX}`. C'est pourquoi chercher TLSA directement sur le domaine ne trouve jamais rien.
- « DANE non configuré » n'est pas une erreur. DANE est une couche de défense supplémentaire pour le chiffrement des e-mails, et la plupart des serveurs de messagerie ne l'utilisent pas encore.
- DANE n'est fiable que si l'enregistrement TLSA du domaine lui-même est protégé par la chaîne de signatures DNSSEC. Même si un enregistrement TLSA est trouvé, utilisez aussi l'outil complémentaire « Vérificateur DNSSEC » pour confirmer que le domaine a bien DNSSEC activé.
- Lorsqu'un domaine possède plusieurs hôtes MX, cet outil vérifie jusqu'à 3 hôtes, en commençant par le numéro de priorité le plus bas (priorité la plus élevée).
- Si les résolveurs ne sont pas d'accord, l'enregistrement vient peut-être d'être mis à jour et les caches ne sont pas encore synchronisés. Patientez puis vérifiez à nouveau.
Questions fréquentes
Anecdote — Protéger le chiffrement des e-mails par des certificats, pas seulement en évitant l'écoute
Le chiffrement des e-mails via SMTP (STARTTLS) présente depuis longtemps une faiblesse. La plupart des serveurs de messagerie utilisent le TLS opportuniste : si l'autre partie ne prend pas en charge le chiffrement, la connexion retombe en clair. Cela a ouvert la voie aux « attaques STRIPTLS », où un attaquant de type homme du milieu retire discrètement la commande STARTTLS, si bien que la connexion se dégrade en clair sans qu'aucune des deux parties ne s'en aperçoive.
DANE (DNS-based Authentication of Named Entities, RFC 6698) répond à ce problème en publiant des enregistrements TLSA dans le DNS. En fixant à l'avance dans le DNS le certificat d'un serveur de messagerie (ou le hachage de sa clé publique), le serveur expéditeur peut vérifier que l'hôte auquel il se connecte présente réellement le certificat attendu. Contrairement à la validation habituelle des certificats SSL/TLS, DANE ne repose absolument pas sur la chaîne de confiance d'une autorité de certification : seule la chaîne de signatures DNSSEC fait foi.
La faiblesse de DANE est qu'il ne fonctionne que si le domaine lui-même est signé avec DNSSEC. Sans DNSSEC, rien n'empêche que l'enregistrement TLSA soit altéré en transit, ce qui rend la garantie de DANE dénuée de sens. C'est pourquoi l'adoption de DANE suit de près celle de DNSSEC, et elle a progressé plus tôt chez certains registres européens (comme .nl et .cz).