Attaques « Man in the Middle », vulnérabilités des certificats… Les techniques de chiffrement du transport de mails DANE et MTA-STS pourraient résoudre certaines de ces problématiques. Voyons comment.
Actuellement, quand deux relais de messagerie doivent échanger des mails, la sécurité du transport des messages est généralement assurée par un chiffrement des échanges en TLS.
Cependant avec TLS, le serveur expéditeur ne peut pas indiquer sa politique de chiffrement et le serveur destinataire ne peut pas la vérifier. Quant aux certificats, ils peuvent être vulnérables :: autorités de certifications (CA) multiples dont certaines ont été compromises, certificats falsifiés ou faibles, , etc. Ce qui peut favoriser des attaques de type « Man in the Middle ».
Les techniques de chiffrement d’échange de mails DANE et MTA-STS devraient résoudre un certain nombre de ces problèmes.
DANE est standardisé par le RFC 7672 d’Octobre 2015. Il permet d’indiquer la politique de chiffrement d’un MX dans un enregistrement TLSA d’un DNSSEC. Pour se faire, on peut utiliser un certificat auto-signé ou validé par une autorité de certification connue. Enfin, l’enregistrement TLSA peut contenir le certificat complet ou un hash du certificat qui sera vérifié par le serveur destinataire.
DANE permet ainsi une validation du certificat utilisé lors de la session TLS avec celui publié via DNSSEC comme illustrée ci-dessous.
Il est dès lors possible de :
À la différence de DANE, MTA STS n’est pas standardisé. Cette solution de chiffrement a été proposée en octobre 2016 par les GAFA comme alternative à DANE. MTA-STS intervient au niveau d’un domaine et non d’un MX notamment quand l’implémentation de DNSSEC n’est pas possible ou non souhaitée.
Cette solution se compose de deux éléments :
Du fait qu’il n’impose pas DNSSEC, MTA-STS est vu par certains comme une solution d’attente avant l’implémentation de DANE ou comme une solution moins contraignante.
À noter, les deux protocoles ne doivent pas interférer : en particulier, une validation MTA –STS ne doit pas outrepasser une validation DANE qui aurait échoué.
Outre le DNSSEC, d’autres différences majeures sont à noter entre les deux solutions. Voici un petit tableau comparatif :
Caractéristique | DANE | STS |
Statut IETF | standardisé | Draft |
DNSSEC | Obligatoire | Recommandé |
Architecture | DNS seulement | DNS + serveur web |
Type de certificat | Auto signé
Signé par une CA | Signé par une CA uniquement |
Type de politique | Par MX
Pas de cache | Par domaine
Utilisation du cache |
Fournisseur de la preuve | DNSSEC | Serveur Web |
Rappelons que ces deux solutions de chiffrement ne permettent qu’un chiffrement durant la phase de transport entre MTA. Pour un chiffrement des mails de bout en bout une solution de chiffrement de type PGP est nécessaire.
Actuellement et du fait qu’il est standardisé, DANE est cours d’implémentation dans la plupart des solutions de sécurité mail. Mais ce n’est encore le cas de MTA-STS.
Toutefois, la combinaison des deux technologies est en train de connaître un certain succès notamment en Hollande pour les instances gouvernementales ou en encore en Allemagne.
Il est donc probable que les deux technologies cohabiteront un certain temps en plus du TLS classique. Ainsi, pour protéger vos échanges de mails, il est important d’implémenter rapidement DANE et sans doute étudier de près MTA STS.
Si vous voulez en savoir plus, voici deux sites intéressants pour connaitre la compatibilité de votre solution avec les nouvelles normes de sécurité du mail ou DANE plus spécifiquement.