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é.
Diagnostiquer la validation des certificats par DANE (enregistrements TLSA)
DANE est l'arrangement par lequel le certificat que présente un serveur de courrier **se valide contre un enregistrement TLSA placé dans le DNS.** Cet outil interroge les enregistrements TLSA publiés par les hôtes MX d'un domaine auprès de plusieurs résolveurs publics et rapporte s'ils sont configurés.
**La prémisse qu'on ne saurait ici omettre est que DANE ne tient que sur DNSSEC.** Ce qui garantit qu'un enregistrement TLSA n'a pas été altéré, c'est DNSSEC lui-même : **poser des enregistrements TLSA sur un domaine sans DNSSEC activé ne revient à aucune protection.** Voilà la différence capitale d'avec MTA-STS : là où MTA-STS place sa confiance dans les certificats web, **DANE la place dans DNSSEC.** L'autre point exigeant de l'attention en exploitation est le renouvellement des certificats, car **remplacer le certificat d'un serveur sans mettre à jour en même temps l'enregistrement TLSA fait échouer la validation et arrête l'arrivée du courrier.** L'ordre requis est d'ajouter d'abord la nouvelle empreinte, de basculer, et de ne retirer l'ancienne qu'ensuite.
Comment s'en servir
- Saisissez le domaine Indiquez le seul domaine, sous la forme `example.com`.
- Regardez le résultat pour chaque hôte MX **Les enregistrements TLSA siègent à `_25._tcp.nomdhote` pour chaque hôte MX.**
- Confirmez la présence de DNSSEC **Sans DNSSEC, un enregistrement TLSA n'offre aucune protection.**
- Planifiez la marche du renouvellement de certificat **Laissez coexister un temps l'ancienne et la nouvelle empreinte avant de basculer.**
Astuces pour en tirer le meilleur parti
- 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.
Dans quels cas s'en servir
Pour inspecter vos propres serveurs de courrier
Vous décelez l'écart où l'on croyait un TLSA posé alors qu'il manque sur l'hôte MX.
Pour vérifier avant de renouveler un certificat
**Se tromper d'ordre arrête le courrier, ce qui rend la vérification préalable largement payante.**
Pour peser DANE face à MTA-STS
**Choisissez selon où vous préférez placer la confiance, dans DNSSEC ou dans les certificats web ; les deux peuvent s'adopter ensemble.**
Pour savoir où en est un correspondant
Vous voyez s'il use de DANE tout court.
Vocabulaire de DANE
- Enregistrement TLSA
- **L'enregistrement plaçant dans le DNS l'empreinte d'un certificat ou d'une clé publique.** Il siège à un nom tel que `_25._tcp.mail.example.com`.
- DNSSEC
- **La prémisse de DANE.** Sans lui, l'enregistrement TLSA pourrait être altéré et nulle protection ne tient.
- Champ d'usage
- Le premier nombre d'un enregistrement TLSA, énonçant s'il vise le certificat lui-même ou une autorité de certification.
- DANE-EE
- L'approche inscrivant l'empreinte du certificat du serveur lui-même. **Elle permet de valider sans dépendre d'aucune autorité.**
- Renouvellement
- Le travail de remplacer un certificat et son enregistrement TLSA. **Ajoutez d'abord la nouvelle empreinte et retirez l'ancienne ensuite.**
- TLS opportuniste
- L'approche ancienne et facultative consistant à chiffrer là où l'autre partie le permet. **DANE et MTA-STS l'élèvent en exigence.**
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).