Qu'est-ce que DANE ? Explication de l'authentification des entités nommées basée sur le DNS

Points clés à retenir

DANE transfère la validation des certificats TLS des autorités de certification tierces vers le DNS, en utilisant des enregistrements TLSA signés par DNSSEC pour établir la confiance.
Cela empêche les attaques par rétrogradation STARTTLS en imposant des connexions chiffrées au lieu d'autoriser un basculement silencieux vers le texte clair.
DANE réduit le risque d'émission erronée ou de compromission des certificats en permettant aux propriétaires de domaines de définir précisément quels certificats sont valides.
Le protocole DNSSEC est indispensable au bon fonctionnement de DANE. Sans lui, les enregistrements TLSA ne peuvent être ni considérés comme fiables ni vérifiés.
Bien que très performant, le protocole DANE est encore peu répandu ; il est donc souvent utilisé en parallèle du protocole MTA-STS et complété par le protocole DMARC pour assurer une sécurité totale des e-mails.

L'authentification des entités nommées via le DNS (DANE) est une méthode permettant de vérifier les certificats TLS à l'aide du DNS. Elle s'appuie sur les enregistrements DNSSEC et TLSA pour garantir que les connexions cryptées ne soient ni interceptées ni déclassées.

Le problème que DANE a été conçu pour résoudre

La transmission d'e-mails via le protocole SMTP (Simple Mail Transfer Protocol) utilise souvent STARTTLS pour sécuriser les connexions par cryptage. Le problème est que STARTTLS fonctionne de manière opportuniste. Cela signifie que si le cryptage échoue, la connexion peut revenir au texte clair. Ce retour en arrière peut se produire de manière silencieuse, ce qui permet aux pirates d'exploiter facilement ce comportement pour intercepter des e-mails.

Le parcours classique :

Le chemin d'attaque :

Le protocole TLS traditionnel présente également un deuxième problème :

Les certificats TLS sont validés par des autorités de certification (CA) commerciales. Ces CA peuvent être compromises ou émettre des certificats de manière incorrecte. Si un pirate parvient à obtenir un certificat valide pour un domaine, il peut se faire passer pour ce serveur.

Ces deux problèmes rendent possibles les attaques de type « man-in-the-middle » même lorsque le protocole TLS est utilisé. Le protocole DANE résout ces deux problèmes en transférant la validation des certificats vers le DNS, sécurisé par le protocole DNSSEC. Cela élimine la dépendance vis-à-vis des autorités de certification externes et empêche les attaques par rétrogradation silencieuse.

Qu'est-ce que DANE ?

DANE est un protocole de sécurité Internet qui permet aux propriétaires de domaines de publier des informations sur leurs certificats TLS directement dans le DNS à l'aide d'enregistrements TLSA.

Ces enregistrements sont protégés par le protocole DNSSEC, qui garantit :

Les données ne peuvent pas être modifiées pendant le transfert
Le client peut vérifier que la réponse est authentique

Au lieu de se fier à une autorité de certification tierce, le client vérifie la validité du certificat par rapport aux informations publiées par le domaine lui-même.

Comment fonctionne DANE : étape par étape

Étape 1 : Le propriétaire du domaine publie un enregistrement TLSA dans le DNS

L'administrateur du domaine crée un enregistrement de ressource TLSA (Transport Layer Security Authentication) et le publie dans sa zone DNS. Cet enregistrement contient les données du certificat que les clients utiliseront ultérieurement à des fins de vérification.

Étape 2 : La zone DNS est signée à l'aide du protocole DNSSEC

Le protocole DNSSEC (DNS Security Extensions) signe cryptographiquement l'ensemble de la zone DNS, y compris le nouvel enregistrement TLSA. Cela permet de créer une chaîne de confiance allant de la zone DNS racine jusqu'aux enregistrements du domaine, empêchant ainsi toute altération.

Étape 3 : Un client se connecte au serveur et interroge l'enregistrement TLSA

Lorsqu'un client (tel qu'un serveur de messagerie ou un navigateur) souhaite établir une connexion TLS avec le serveur, il interroge d'abord le DNS pour obtenir l'enregistrement TLS du domaine.

Étape 4 : Le client valide la réponse DNS à l'aide du protocole DNSSEC

Avant de se fier à l'enregistrement TLSA, le résolveur du client valide les signatures DNSSEC en remontant la chaîne de confiance.

Étape 5 : Le serveur présente son certificat TLS

Au cours de la négociation TLS, le serveur envoie son certificat TLS au client afin de prouver son identité en présentant sa chaîne de certificats.

Étape 6 : Le client compare le certificat avec l'enregistrement TLSA

Il s'agit de l'étape la plus importante de la vérification DANE. À ce stade, le client extrait la partie pertinente du certificat du serveur et la compare aux données stockées dans l'enregistrement TLSA.

Étape 7 : Si les informations correspondent, la connexion s'établit

Lorsque les données du certificat correspondent à l'enregistrement TLSA, la validation DANE aboutit, ce qui permet d'établir la connexion TLS avec succès.

Étape 8 : Si elles ne correspondent pas, la connexion est refusée

Lorsque le certificat ne correspond pas à l'entrée TLSA, le client considère cela comme une faille de sécurité et refuse de mener à bien la négociation TLS. Cela empêche d'emblée les attaques de type « man-in-the-middle » de aboutir.

Qu'est-ce qu'un enregistrement TLSA ?

Un enregistrement TLSA est un enregistrement DNS utilisé par DANE pour définir la manière dont un certificat TLS doit être validé.

The format looks like this: <usage> <selector> <matching-type> <certificate-data>

Exemple d'enregistrement TLSA :

_25._tcp.mail.example.com. IN TLSA 3 1 1 (

2A3F5C7D8E9B1A2C3D4E5F67890123456789ABCDEF1234567890ABCDEF123456
)

Chaque champ a une fonction spécifique :

Utilisation: définit comment le certificat doit être vérifié et considéré comme fiable
Sélecteur: indique quelle partie du certificat est utilisée (certificat complet ou clé publique)
Type de correspondance: indique comment les données sont stockées (valeur complète ou hachage)
Données du certificat: la valeur réelle ou le hachage à comparer

Valeurs d'utilisation des certificats

Il existe quatre types d'utilisation :

0 (PKIX-TA): Ancrage de confiance utilisant une infrastructure PKI traditionnelle
1 (PKIX-EE): Certificat d'entité finale validé via une infrastructure PKI
2 (DANE-TA): Ancrage de confiance défini par le DNS
3 (DANE-EE): Certificat d'entité finale défini directement dans le DNS

En matière de sécurité des e-mails, les niveaux d'utilisation 2 et 3 sont les plus pertinents, car ils permettent de ne plus dépendre des autorités de certification publiques.

Où sont publiés les registres TLSA

Les enregistrements TLSA sont publiés sous des sous-domaines spécifiques liés aux services. Pour le protocole SMTP, cela se présente généralement sous la forme suivante : _25._tcp.mail.example.com

DANE pour la messagerie électronique : comment cela sécurise le protocole SMTP

Le protocole DANE aide le serveur émetteur à vérifier l'authenticité des certificats du serveur destinataire. Cette vérification permet d'empêcher les attaques par rétrogradation STARTTLS et les attaques de type « man-in-the-middle », contribuant ainsi à sécuriser les communications SMTP.

DANE impose l'utilisation du protocole TLS pour la transmission des e-mails, ce qui empêche l'envoi de messages en clair ou leur altération pendant le transfert.

Pourquoi DANE nécessite DNSSEC

Le protocole DANE repose entièrement sur l'intégrité des enregistrements DNS. Sans DNSSEC, les enregistrements TLSA pourraient être falsifiés, et des pirates pourraient rediriger les clients vers des certificats malveillants. Voici comment fonctionne cette dépendance : le protocole DNSSEC signe les réponses DNS à l'aide de clés cryptographiques. Cela permet au client de vérifier que la réponse n'a pas été altérée et que les données sont authentiques. Par conséquent, sans DNSSEC, le protocole DANE n'offre aucun avantage réel en matière de sécurité.

Qui utilise DANE ?

L'adoption de DANE varie d'un pays à l'autre, les taux les plus élevés étant observés parmi les agences gouvernementales européennes et les organisations américaines. Son adoption progresse dans les secteurs où la confidentialité des e-mails est essentielle. Parmi les utilisateurs courants de DANE, on trouve :

Les administrateurs de messagerie comme niveau supplémentaire d'authentification et de sécurité
Les administrations publiques des pays européens et des États-Unis, afin de sécuriser la transmission des e-mails dans le secteur public (par exemple : l'opérateur allemand T-Online utilise déjà DANE dans la pratique)
Fournisseurs de messagerie électronique tels que Comcast, Protonmail, etc.
Microsoft a annoncé la prise en charge du protocole SMTP entrant DANE à compter de juillet 2024.

DANE vs MTA-STS : quelle est la différence ?

DANE et le protocole MTA-STS (Mail Transfer Agent – Strict Transport Security) ont tous deux pour objectif de sécuriser les connexions SMTP, mais ils reposent sur des modèles de confiance différents. Alors que le protocole MTA-STS s'appuie sur le protocole HTTPS et les autorités de certification (CA), DANE s'appuie sur le protocole DNSSEC et le DNS. Voici quelques-unes des principales différences entre les deux :

Fonctionnalité	DANE	MTA-STS
DNSSEC obligatoire	Oui	Non
Emplacement de la police	DNS	Fichier de stratégie HTTPS
dépendance CA	En option	Requis
Protection contre la baisse de notation	Fort	Fort
Adoption	Faible	Haut

Pour en savoir plus sur MTA-STS, consultez notre guide complet intitulé « Qu'est-ce que MTA-STS? ». Pour découvrir comment mettre en œuvre MTA-STS sur votre domaine, consultez notre guide de mise en œuvre de MTA-STS.

Fonctionnement de TLS-RPT en association avec DANE et MTA-STS

TLS-RPT est un protocole de signalement qui permet de mettre en évidence les échecs de négociation TLS et les problèmes de livraison dus à des erreurs de configuration de DANE ou de MTA-STS. On peut considérer TLS-RPT comme une couche de visibilité superposée à DANE et MTA-STS (couches de sécurité). Si DANE et MTA-STS contribuent tous deux à renforcer la sécurité des transmissions de courrier électronique via TLS, il existe toutefois un manque crucial de clarté quant au moment et à la raison pour lesquels la livraison échoue.

C'est là qu'intervient le protocole TLS-RPT. Le protocole de rapport SMTP TLS (TLS-RPT) renvoie quotidiennement aux serveurs destinataires des rapports de retour d'information agrégés concernant :

Échecs de négociation TLS
Problèmes liés à la validation des certificats
Incompatibilités entre les protocoles (MTA-STS ou DANE)
Échecs de livraison dus à l'application du protocole TLS

Comment vérifier si votre domaine dispose d'un enregistrement DANE/TLSA

Pour vérifier la configuration DANE, vous devez vérifier les points suivants :

Vérifier s'il existe un enregistrement TLSA pour votre serveur de messagerie
Si le protocole DNSSEC est activé et valide
Si le certificat correspond à l'enregistrement TLSA

Vous pouvez utiliser l'outil gratuit de vérification des enregistrements DANE de PowerDMARC pour valider rapidement votre configuration.

Comment mettre en œuvre DANE pour la messagerie électronique

Pour mettre en place le protocole DANE pour votre messagerie électronique, vous pouvez suivre les étapes ci-dessous :

Étape 1 : Activer le protocole DNSSEC

DANE ne peut pas fonctionner sans DNSSEC ; la première étape consiste donc à configurer DNSSEC auprès de votre fournisseur de DNS ou de votre registraire. Vous pouvez vérifier si cette fonctionnalité est déjà configurée pour votre domaine à l'aide de notre outil de vérification DNSSEC.

Étape 2 : Récupérez les données de votre certificat TLS

Récupérez le certificat ou le hachage de la clé publique de votre serveur de messagerie.

Étape 3 : Créer l'enregistrement TLSA

Définissez l'utilisation, le sélecteur et le type de correspondance appropriés, puis publiez votre enregistrement TLSA sous le sous-domaine correspondant.

Étape 4 : Valider l'enregistrement

Utilisez notre outil de vérification DANE pour vous assurer que l'enregistrement est correct et que le protocole DNSSEC fonctionne correctement.

Étape 5 : Surveiller les modifications apportées aux certificats

Lorsque votre certificat TLS est renouvelé ou modifié, l'enregistrement TLSA doit être mis à jour. Si vous ne le faites pas, cela peut perturber la distribution du courrier.

En conclusion

Si vous ne sécurisez pas encore la couche de transport de vos e-mails à l'aide du protocole MTA-STS, le protocole DANE peut constituer un excellent point de départ. En particulier dans les secteurs traitant des données sensibles, tels que les institutions financières et les organismes du secteur public, il est essentiel de protéger les messages contre toute interception.

Cependant, DANE ne peut pas empêcher les attaques par usurpation d'identité ou par hameçonnage utilisant votre propre nom de domaine. Pour cela, DMARC est indispensable. Vous recherchez une solution complète de sécurité de domaine qui gère l'authentification de vos e-mails de A à Z ? Prenez rendez-vous dès aujourd'hui pour une démonstration avec nos experts.

Foire aux questions

DANE, c'est la même chose que DNSSEC ?

Non, DANE et DNSSEC ne sont pas identiques, même si DANE nécessite DNSSEC pour fonctionner. DNSSEC sécurise les enregistrements DNS, tandis que DANE utilise DNSSEC pour publier en toute sécurité les informations relatives aux certificats.

Ai-je besoin à la fois de DANE et de MTA-STS ?

Ce n'est pas forcément le cas, mais l'utilisation des deux protocoles offre une compatibilité plus large et une protection plus efficace. Dans l'ensemble, le protocole MTA-STS est plus largement adopté que le protocole DANE.

Le protocole DANE remplace-t-il SPF, DKIM ou DMARC ?

Non. DANE sécurise la couche de transport, tandis que SPF, DKIM et DMARC assurent l'authentification des e-mails et la prévention de l'usurpation d'identité. Pour une sécurité complète des e-mails, il est nécessaire d'adopter une approche multicouche combinant tous ces protocoles, ainsi qu'une surveillance et des mises à jour régulières.

Que se passe-t-il si mes données TLSA sont erronées ?

Si votre enregistrement TLSA est incorrect, les serveurs de messagerie qui appliquent le protocole DANE rejetteront les connexions. Cela peut entraîner des échecs de livraison des e-mails. Il est important de vérifier votre configuration DANE (y compris la validité de votre enregistrement TLSA) afin de résoudre tout problème éventuel.

Quels fournisseurs de messagerie prennent en charge le protocole DANE ?

La prise en charge du protocole DANE varie d'un pays à l'autre. Certains fournisseurs européens et certaines organisations spécialisées dans la sécurité l'imposent, mais son adoption à l'échelle mondiale reste encore limitée.

À propos de
Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des courriels chez PowerDMARC

Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.

Derniers messages de Ahona Rudra (voir tous)

Qu'est-ce que DANE ? Explication de l'authentification des entités nommées basée sur le DNS (2026)