DANE pour sécuriser les échanges SMTP

L’échange de messages informatiques entre serveurs se fait principalement par l’intermédiaire du protocole SMTP (Simple Mail Transfer Protocol). Ce protocole n’est pas nativement sécurisé, ce qui ouvre la possibilité à un intermédiaire d’intercepter et espionner ces communications.

Pour sécuriser ces flux, il est possible d’utiliser TLS (Transport Layer Security), un protocole qui permet le chiffrement des échanges. Malheureusement, rien dans la communication SMTP ne permet d’informer le serveur émetteur de la capacité de chiffrement du serveur destinataire. La parade, largement déployée, à ce problème est d’utiliser un chiffrement opportuniste (StartTLS). Celui-ci permet, à l’issue d’une première communication non chiffrée, d’informer chacun des serveurs sur leurs capacités de chiffrement respectives et ainsi de sélectionner le meilleur algorithme compatible pour la suite de la communication.

Le schéma ci-dessous détaille le fonctionnement et les étapes d’une communication SMTP sécurisée sous StartTLS lors de l’envoi d’un email de l’utilisateur « from@exp.fr » vers « to@dest.fr ».

L’utilisation du chiffrement opportuniste présente néanmoins des limites. Il est notamment sensible aux attaques de l’homme du milieu (Man-In-The-Middle en anglais), une interception du flux qui peut mener à l’espionnage voire à la modification d’une communication. C’est lors du premier contact, non chiffré, entre les deux serveurs que cette faille est exploitable. Une fois le flux intercepté, il est possible pour l’attaquant de compromettre l’intégrité du transfert. Voici la présentation de deux des attaques possibles: 

Attaque par repli

Le principe de cette attaque est que, lors de la communication initiale, l’attaquant va modifier la réponse du serveur destinataire indiquant sa capacité de chiffrement (étape [4] du schéma ci-dessus). Il va informer à la place l’émetteur que le serveur destinataire ne permet qu’une communication non sécurisée (pas de TLS). Il pourra alors, en continuant à intercepter le flux, lire le contenu non chiffré du trafic entre les machines.

Attaque par modification du certificat

Par défaut, les serveurs de messagerie ne vérifient pas la validité d’un certificat reçu. Historiquement, beaucoup de serveurs de messagerie avaient des certificats autosignés ou invalides. Il est donc dans l’usage de vérifier la présence d’un certificat, mais pas son statut.

Ceci permet à l’attaquant, lors d’une interception de trafic, de modifier la réponse du serveur destinataire (étape [6] du schéma ci-dessus). Il indique alors un autre certificat, correspondant à un autre serveur. La connexion est donc bel et bien sécurisée, mais avec l’attaquant, qui relaye les demandes au serveur destinataire, en les lisant voire en les modifiant au passage.

Il existe néanmoins des solutions pour combler ces failles. Des techniques qui permettent au serveur émetteur de vérifier les informations (capacité de chiffrement, certificats, version du protocole, etc) transmises lors de l’initialisation non-chiffrée de la communication StartTLS.

Fonctionnement de DANE

DANE (DNS-based Authentification of Named Entities) est un protocole standardisé (RFC 7672) qui permet d’indiquer par l’intermédiaire d’un enregistrement DNS dédié (TLSA) qu’un serveur utilise bien le chiffrement TLS. Il fournit de plus une empreinte de la clé de chiffrement afin de rendre les usurpations impossibles. La mise en place de DANE implique deux contraintes :

– L’empreinte présente dans l’enregistrement TLSA doit être mise à jour lors du renouvellement du certificat.

– La communication DNS doit être sécurisée par DNSSEC, afin d’assurer qu’il n’y ait de falsification au niveau de la récupération de cette empreinte.

DANE fonctionne au niveau des serveurs (et non du domaine). Il doit être configuré au niveau du serveur de messagerie et dans les DNS du nom d’hôte de ce serveur. Techniquement, il est capable de sécuriser n’importe quel service utilisant TLS, mais c’est dans la messagerie qu’il est le plus courant. C’est actuellement la meilleure solution pour assurer la sécurité des communications entre serveurs.

Alternative à DANE: MTA-STS

MTA-STS (Mail Transfer Agent – Strict Transport Security) est un mécanisme, initié et poussé par Google, qui permet, par l’intermédiaire d’une politique accessible en HTTPS, d’annoncer aux serveurs émetteurs si un serveur destinataire impose le chiffrement TLS. Il utilise une politique accessible par l’intermédiaire d’un serveur Web qui indique les serveurs de messagerie du destinataire. Ce document intègre un identifiant qui doit être mis à jour en cas de changement de politique. Contrairement à DANE, MTA-STS agit au niveau du domaine plutôt qu’au niveau du serveur, il est purement destiné à la messagerie.

MTA-STS est considéré comme moins pertinent que DANE, principalement pour deux raisons :

– Le domaine doit intégrer un serveur Web, qu’il faut lui-même entretenir et sécuriser.

– La validation des certificats repose sur les autorités de certification connues de l’émetteur, là où DANE valide le certificat par sa cohérence avec l’empreinte, ce qui prend en compte notamment les certificats autosignés ou issus d’autorités de certification inconnues de l’émetteur.

Heureusement, les deux techniques n’interfèrent pas entre elles et sont pleinement compatibles. L’idéal est donc d’exploiter les deux systèmes afin que les serveurs émetteurs aient le choix du protocole à utiliser.

La solution française de protection des emails Altospam utilise DANE pour protéger la messagerie de ses clients et peut les accompagner dans la mise en place d’une politique MTA-STS afin d’assurer une sécurisation optimale.

Pour accroître la sécurité de votre messagerie électronique ou comprendre la mise en place de DANE et MTA-STS, vous pouvez suivre la procédure décrite dans l’article : Comment optimiser la sécurité de sa messagerie électronique ? La protection des emails passe aussi par la sécurisation de son flux de messagerie et les protocoles et algorithmes de chiffrement autorisés.