Le système des autorités de certification a un problème fondamental : n’importe laquelle des centaines de CA peut émettre un certificat pour n’importe quel domaine. Si une CA est compromise, piratée, ou contrainte par un gouvernement, elle peut émettre des certificats frauduleux que les navigateurs et les serveurs de messagerie accepteront. Cela s’est déjà produit—DigiNotar, Comodo, WoSign—et cela se reproduira.
Pour la navigation web, nous avons développé des mesures d’atténuation : les journaux Certificate Transparency, les enregistrements CAA, la supervision des éditeurs de navigateurs. Mais l’email a historiquement été plus vulnérable. Les serveurs de messagerie qui se connectent entre eux n’ont pas le même écosystème de protections.
DANE—DNS-based Authentication of Named Entities—propose une approche entièrement différente. Au lieu de faire confiance aux autorités de certification, vous publiez vos informations de certificat directement dans DNS, sécurisé par DNSSEC. Le serveur émetteur n’a pas besoin de faire confiance à une CA ; il lui suffit de faire confiance à DNS, ce qu’il fait déjà pour tout le reste.
Le problème que DANE résout
Quand votre serveur de messagerie se connecte à un autre serveur pour livrer des emails, il doit vérifier qu’il parle au bon serveur. Sans vérification, un attaquant pourrait intercepter la connexion et usurper la destination.
La vérification TLS traditionnelle utilise des autorités de certification. Le serveur de destination présente un certificat, votre serveur vérifie qu’il est signé par une CA de confiance, et si c’est le cas, continue. Mais ce modèle de confiance a des faiblesses.
D’abord, il y a trop de CA de confiance. Par défaut, votre serveur fait probablement confiance à des centaines d’autorités de certification. N’importe laquelle d’entre elles pourrait émettre un certificat pour n’importe quel domaine. Une CA compromise dans un pays pourrait émettre des certificats utilisés pour intercepter des emails partout dans le monde.
Ensuite, le chiffrement opportuniste est vulnérable aux attaques de rétrogradation. Si un attaquant peut intercepter la connexion initiale, il peut supprimer la proposition TLS et forcer une communication en clair. Les serveurs ne savent pas qu’ils doivent exiger le chiffrement.
DANE répond aux deux problèmes. Il permet aux propriétaires de domaines de spécifier exactement quels certificats sont valides pour leurs serveurs, publiés dans des enregistrements DNS signés cryptographiquement. Aucune confiance dans les CA n’est requise. Et comme la politique est dans DNS, les serveurs émetteurs savent qu’ils doivent exiger le chiffrement avant même de se connecter.
Comment fonctionne DANE
DANE utilise un type d’enregistrement DNS spécial appelé TLSA (Transport Layer Security Authentication). Cet enregistrement spécifie quel certificat le serveur doit présenter, publié à un emplacement précis dans DNS.
Le nom DNS suit un schéma : _port._protocol.hostname. Pour un serveur de messagerie à mail.example.com utilisant SMTP (port 25), l’enregistrement TLSA se trouverait à _25._tcp.mail.example.com. Cette précision vous permet de spécifier des certificats différents pour des services différents sur le même hôte.
L’enregistrement TLSA contient plusieurs champs. Le champ usage spécifie comment valider le certificat—s’il faut le vérifier via une CA, l’utiliser directement, ou l’utiliser comme ancre de confiance. Le champ selector indique si vous spécifiez le certificat complet ou seulement la clé publique. Le champ matching type précise si vous incluez les données complètes ou un hash.
La plupart des déploiements DANE pour l’email utilisent le type d’usage 3 (DANE-EE), qui signifie « voici le certificat ou la clé publique exacte que le serveur présentera, faites-lui confiance directement ». Cela contourne complètement le système des CA—vous dites aux émetteurs exactement à quoi s’attendre.
DNSSEC : le fondement
DANE ne fonctionne que avec DNSSEC. Sans DNSSEC, un attaquant capable de manipuler les réponses DNS pourrait publier de faux enregistrements TLSA pointant vers ses propres certificats. DNSSEC fournit l’authentification cryptographique qui rend DANE fiable.
DNSSEC ajoute des signatures numériques aux enregistrements DNS. Chaque enregistrement est signé par la clé de la zone, elle-même authentifiée par la clé de la zone parente, jusqu’à la racine. Un serveur émetteur peut vérifier toute la chaîne, garantissant que l’enregistrement TLSA reçu est authentique.
C’est à la fois la force et la limitation de DANE. DNSSEC fournit une authentification forte sans faire confiance à des CA tierces. Mais le déploiement de DNSSEC reste incomplet. Beaucoup de domaines n’ont pas DNSSEC, et de nombreux résolveurs DNS ne le valident pas. Si votre domaine n’a pas DNSSEC, vous ne pouvez pas utiliser DANE.
Mettre en place DANE pour l’email
Implémenter DANE nécessite plusieurs étapes, et l’ordre est important.
D’abord, assurez-vous que votre domaine a DNSSEC. Cela implique généralement de travailler avec votre fournisseur DNS pour activer la signature et publier des enregistrements DS dans la zone parente. De nombreux fournisseurs DNS prennent désormais en charge DNSSEC, mais la configuration varie.
Ensuite, obtenez ou identifiez le certificat utilisé par votre serveur de messagerie. Vous avez besoin soit du certificat complet, soit de sa clé publique, selon le type de selector que vous choisissez. Utiliser la clé publique (selector 1) est souvent préférable car elle survit aux renouvellements de certificats tant que vous conservez la même clé.
Troisièmement, générez l’enregistrement TLSA. Vous hasherez le certificat ou la clé publique avec SHA-256 (matching type 1) et le formaterez en enregistrement TLSA. Des outils existent pour automatiser cela—vous n’avez pas besoin de faire le hash manuellement.
Quatrièmement, publiez l’enregistrement TLSA dans DNS. Rappelez-vous la convention de nommage : _25._tcp.yourmailserver.example.com pour SMTP. L’enregistrement doit être en place et signé par DNSSEC avant que les émetteurs ne l’utilisent.
Enfin, testez minutieusement. Les échecs DANE peuvent provoquer des échecs de livraison d’email, donc vérifiez que tout fonctionne avant de vous y fier. Plusieurs outils en ligne peuvent vérifier votre configuration DANE et signaler les problèmes.
DANE vs MTA-STS
DANE et MTA-STS résolvent des problèmes similaires—tous deux empêchent les attaques de rétrogradation TLS et la substitution de certificats. Mais ils fonctionnent différemment et présentent des compromis distincts.
DANE exige DNSSEC mais offre des garanties de sécurité plus fortes. L’authentification du certificat est cryptographique et ne dépend d’aucun tiers au-delà de la hiérarchie DNS. Si DNSSEC est compromis, vous avez des problèmes plus graves que la sécurité des emails.
MTA-STS n’exige pas DNSSEC mais demande l’hébergement d’un fichier de politique via HTTPS. Il s’appuie sur la PKI du Web (autorités de certification) pour authentifier le fichier de politique. C’est sans doute moins solide que DNSSEC, mais c’est plus déployable aujourd’hui.
En pratique, MTA-STS a connu une adoption plus large car le déploiement de DNSSEC reste limité. Google, Microsoft et la plupart des grands fournisseurs d’email prennent en charge MTA-STS. Le support de DANE est moins universel, bien qu’il progresse.
Si vous avez DNSSEC, implémenter DANE offre la protection la plus forte. Si vous n’avez pas DNSSEC et ne pouvez pas l’obtenir facilement, MTA-STS est le choix pratique. Implémenter les deux offre une défense en profondeur—les émetteurs qui prennent en charge DANE l’utiliseront, les autres basculeront vers MTA-STS.
Erreurs DANE courantes
Le problème DANE le plus fréquent est des enregistrements TLSA qui ne correspondent pas au certificat réel. Cela arrive quand les certificats sont renouvelés sans mise à jour du DNS, ou quand les mauvaises données de certificat sont publiées initialement. Le résultat, ce sont des échecs de livraison—les serveurs émetteurs voient une incompatibilité et refusent de livrer.
L’automatisation aide ici. Si vous utilisez Let’s Encrypt ou un autre système de certificats automatisé, intégrez les mises à jour des enregistrements TLSA dans votre processus de renouvellement. Certains outils gèrent cela automatiquement ; d’autres nécessitent du scripting.
Un autre problème courant vient des configurations DNSSEC. DANE exige un DNSSEC valide sur toute la chaîne. Si vos signatures DNSSEC expirent, ou s’il y a une erreur de configuration, la validation DANE échoue. Surveillez en continu l’état de votre DNSSEC.
Publier des enregistrements TLSA avant que DNSSEC ne soit pleinement déployé pose aussi problème. Les émetteurs qui prennent en charge DANE tenteront de valider, échoueront parce que DNSSEC ne fonctionne pas, et peuvent rejeter l’email. Faites d’abord fonctionner DNSSEC, vérifiez-le soigneusement, puis ajoutez les enregistrements TLSA.
Faut-il implémenter DANE ?
Pour les organisations avec des exigences élevées de sécurité et une infrastructure DNSSEC existante, DANE est la référence absolue pour la sécurité du transport des emails. Il fournit une authentification cryptographique sans faire confiance aux autorités de certification, ce qui compte si vous êtes concerné par des acteurs étatiques ou la compromission de CA.
Pour la plupart des organisations, la réponse pratique dépend de DNSSEC. Si vous avez déjà DNSSEC (peut-être pour d’autres raisons), ajouter DANE est relativement simple et apporte de vrais bénéfices de sécurité. Si vous n’avez pas DNSSEC, l’effort pour le mettre en place uniquement pour DANE peut ne pas se justifier—MTA-STS offre une protection similaire avec moins d’infrastructure.
L’écosystème email évolue progressivement vers l’exigence d’un chiffrement du transport. Que ce soit via DANE, MTA-STS, ou les deux, la direction est claire. Implémenter l’un ou l’autre dès maintenant vous met en avance et protège vos emails contre l’interception.
Frequently asked questions
Puis-je utiliser DANE sans DNSSEC ?
Non. DANE repose fondamentalement sur DNSSEC pour l’authentification. Sans DNSSEC, un attaquant pourrait forger des enregistrements TLSA, ce qui annule entièrement l’objectif. DNSSEC est un prérequis, pas une option.
Que se passe-t-il si mon enregistrement TLSA est erroné ?
Les serveurs émetteurs qui prennent en charge DANE ne livreront pas d’email chez vous. Ils constateront une incompatibilité entre l’enregistrement TLSA et votre certificat réel et refuseront de se connecter. C’est pourquoi les tests sont critiques avant le déploiement.
Les grands fournisseurs d’email prennent-ils en charge DANE ?
Le support progresse mais n’est pas universel. Certains fournisseurs européens et des organisations axées sur la sécurité prennent en charge DANE. Google a indiqué un support dans certains contextes. Vérifiez la compatibilité actuelle avant de vous appuyer sur DANE pour des flux d’email critiques.
Dois-je utiliser DANE ou MTA-STS ?
Si vous avez DNSSEC, utilisez DANE—c’est plus sécurisé. Si vous n’avez pas DNSSEC, utilisez MTA-STS. Si vous avez DNSSEC et souhaitez une protection maximale, implémentez les deux. Ils sont complémentaires, pas concurrents.