En tant que technologie de communication numérique, le courrier électronique continue de dominer et de croître en utilisation. Dans mon article précédent, j'ai souligné bon nombre de ses vertus, mais j'ai également fait allusion à certaines faiblesses que la plupart des utilisateurs ignorent totalement.

Dans cet article, nous explorerons ces faiblesses plus en détail et plus particulièrement la manière dont les e-mails sont transmis entre les serveurs. Nous soulignerons également comment ces faiblesses peuvent être résolues grâce à l'adoption accrue d'extensions établies pour les protocoles de messagerie traditionnels (par exemple, DANE).

Comme toujours, cet article est basé sur mes recherches personnelles et ma pratique sur le sujet, mais le partage des connaissances est une collaboration, alors n'hésitez pas à fournir des commentaires ou des commentaires.

Introduction

Pour faciliter la compréhension, je soulignerai trois phases de haut niveau de la façon dont les connexions entre les serveurs de messagerie sont établies.

Découverte du serveur de messagerie des destinataires , le processus de découverte du serveur de messagerie censé accepter le courrier pour un domaine de destinataires donné.

Connexion au serveur de messagerie des destinataires, après avoir identifié le bon serveur de messagerie, le processus de connexion à celui-ci et la sécurisation de la connexion avec un cryptage approprié (alias TLS).

La vérification que le serveur de messagerie des destinataires est bien le bon, pouvons-nous être certains que nous avons établi une connexion sécurisée au serveur légitime pour le domaine des destinataires.

Découverte du serveur de messagerie des destinataires

Ceci est le plus souvent réalisé via une recherche DNS des enregistrements MX (Mail Exchange) qui pointent vers une ou plusieurs adresses IP de serveurs de messagerie destinés à recevoir du courrier pour le domaine des destinataires. Cependant, il existe d'autres mécanismes tels que MTA-STS, les enregistrements SRV ou même les enregistrements A. Nous couvrirons certains éléments de MTA-STS plus loin, mais pas les approches d'enregistrement SRV/A (bien qu'elles partagent les mêmes faiblesses).

La découverte des serveurs de messagerie repose sur DNS , et la grande majorité des requêtes DNS reposent toujours sur des paquets UDP et sont donc sans connexion et non chiffrées, ce qui rend relativement facile l'interception et l'injection de réponses falsifiées.

Bien qu'il existe des implémentations de DNS qui utilisent TCP, TLS et même DNS sur HTTPS , elles sont plutôt rares mais réduisent le potentiel d'interception et d'injection entre le client et le serveur.

Cependant, le déploiement de TCP/TLS se concentre sur l'amélioration ou la sécurisation de la connexion, ils ne fournissent pas eux-mêmes un mécanisme pour garantir que les données, les réponses aux recherches DNS, sont authentiques et n'ont pas été falsifiées.

C'est là qu'intervient DNSSEC , il fournit une approche de signature numérique ancrée dans la confiance qui garantit que toutes les réponses DNS pour les domaines activés DNSSEC peuvent être validées cryptographiquement comme étant authentiques et faisant autorité.

Qu'en est-il de DANE ?

• DANE requiert DNSSEC pour toutes les recherches DNS, ce qui atténue ce risque avec succès.

• MTA-STS publie les serveurs de messagerie, faisant autorité pour un domaine, en les répertoriant dans un fichier de stratégie MTA-STS hébergé sur un serveur Web. Bien que la connexion au serveur Web lui-même puisse être HTTPS (avec validation du certificat), il n'est pas nécessaire que la recherche DNS de ce serveur Web soit sécurisée.
• MTA-STS n'impose pas l'utilisation de DNSSEC, en fait, je crois comprendre que l'une de ses «caractéristiques de conception» était qu'il ne dépendait pas de DNSSEC.

• La découverte d'un serveur de messagerie de domaines destinataires dépend du DNS qui, sans DNSSEC, n'a pas la sécurité nécessaire pour garantir les réponses reçues.
• DANE rend obligatoire l'utilisation de DNSSEC, donc en tant qu'extension de SMTP, c'est le mécanisme le plus efficace pour fournir une protection contre ce risque.
• MTA-STS n'impose pas l'utilisation de DNSSEC et malgré l'hébergement de la politique sur un serveur sécurisé HTTPS, s'appuie toujours sur une recherche DNS traditionnelle.
• Cependant, MTA-STS pourrait être déployé avec DNSSEC, ce qui atténuerait une grande partie de ce risque. Ce serait ma recommandation si vous êtes en train de déployer MTA-STS.

Le monde est passé au HTTPS en un clin d'œil. Il est très inhabituel aujourd'hui de trouver un site Web qui ne prend pas en charge HTTPS (même ceux qui ne prennent pas les détails de votre carte de crédit). Cependant, le courrier électronique n'a pas connu le même changement radical en matière de sécurité et s'appuie toujours sur ce que nous appelons le "TLS opportuniste". Dans TLS opportuniste, les serveurs établiront d'abord une connexion non sécurisée, puis tenteront de négocier et de mettre à niveau la connexion vers TLS, mais continueront volontiers sans TLS si, pour une raison quelconque, ils ne peuvent pas s'entendre.

Le vrai problème ici est que "Opportunistic TLS" ouvre initialement une connexion non sécurisée et la met à niveau vers TLS (initié par la méthode STARTTLS). Il est donc relativement facile d'intercepter une telle connexion et d'inhiber la mise à niveau vers TLS en masquant le support STARTTLS du serveur distant. Les serveurs de messagerie TLS opportunistes continueront alors l'échange d'e-mails sans souci ni considération. Pire encore, ni l'expéditeur ni les destinataires ne sauraient à distance que cela s'est produit.

Les deux parties d'une connexion TLS utilisent des certificats PKI qui peuvent également être utilisés pour fournir des niveaux de confiance supplémentaires que les parties sont bien ce qu'elles prétendent être et vérifiables indépendamment via une ancre de confiance . Cependant, compte tenu de la facilité avec laquelle il est possible d'obtenir des certificats auprès de fournisseurs tels que LetsEncrypt, cela devient moins fiable.

En pratique, la grande majorité des serveurs de messagerie prennent en charge une certaine forme de TLS et il y a donc une probabilité assez élevée que votre e-mail ait été crypté lorsqu'il a traversé Internet jusqu'à sa destination. Cependant, il ne traite pas le risque d'une attaque MITM masquant la prise en charge de TLS et permettant des connexions non chiffrées.

Qu'en est-il du MTA-STS ?

• MTA-STS résout ce risque en exigeant implicitement (et en supposant que vous n'êtes pas en mode "test") qu'une connexion TLS soit établie pour l'échange d'e-mails.

• DANE applique l'exigence implicite d'une connexion TLS et atténue ainsi ce risque.

• TLS opportuniste s'appuie sur une connexion non chiffrée pour établir la possibilité d'une mise à niveau vers TLS et est donc vulnérable à une attaque MITM.
• DANE et MTA-STS nécessitent implicitement une connexion TLS avant l'échange d'e-mails, ils sont donc efficaces pour garantir qu'au moins une connexion TLS de base est établie.
• TLS seul n'est pas suffisant pour suggérer qu'une connexion est suffisamment sécurisée/cryptée. De nombreux protocoles et suites de chiffrement implémentés dans TLS sont considérés comme non sécurisés (brute forcable). C'est tout un sujet en soi que nous aborderons dans un article ultérieur.

Il s'agit sans doute d'une étape dans le processus d'établissement d'une connexion sécurisée entre les serveurs de messagerie. Cependant, à mon avis, c'est un élément tellement critique qu'il mérite sa propre section.

Reconnaissant la dépendance aux phases précédentes, il devient essentiel que nous puissions valider davantage que le serveur auquel nous nous connectons est bien le serveur qui fait autorité pour le domaine des destinataires. La première phase décrit l'établissement d'une connexion TLS qui peut ou non inclure la vérification de certificat. Cependant, en général, toute vérification de certificat consiste généralement à valider que le nom d'hôte donné correspond au nom d'hôte détaillé dans le certificat sur le serveur distant et éventuellement s'il peut être lié à l'ancre de confiance.

DANE va encore plus loin en publiant un enregistrement TLSA sécurisé DNSSEC qui contient une empreinte digitale (et une méthode de validation) pour le certificat de serveur de messagerie donné. Cela fournit une validation fiable et ultime qui garantit catégoriquement que le serveur auquel vous vous connectez présente le certificat spécifique reconnu par l'administrateur DNS.

Qu'en est-il de DANE ?

• La validation du certificat des serveurs par rapport à un enregistrement TLSA sécurisé DNSSEC est inhérente à DANE et fournit le sceau d'approbation final pour assurer la connexion.

• MTA-STS ne va pas aussi loin, son objectif est de s'assurer qu'une connexion TLS est obligatoire et ne s'étend pas à la validation de l'autorité des serveurs de messagerie.

Dans mon esprit, il n'y a aucune raison rationnelle pour que ces faiblesses ne soient pas atténuées chez la majorité des fournisseurs de messagerie. La technologie existe pour y répondre et est relativement facile à déployer de nos jours. Mon hypothèse étant que le manque de sensibilisation des consommateurs supprime une grande partie de l'incitation pour les fournisseurs de messagerie à mettre en œuvre ces technologies.

MTA-STS fournit quelques améliorations clés aux problèmes de TLS opportuniste, mais ne va pas assez loin pour résoudre toutes les faiblesses. L'ajout de DNSSEC à MTA-STS réduit certains des risques et serait ma recommandation (si DANE n'est pas une option pour vous).

DANE fournit cependant une solution complète aux faiblesses abordées dans cet article. Si vous envisagez à la fois MTA-STS et DANE mais que vous ne voulez en choisir qu'un, alors DANE serait ma recommandation.

Il y a environ 365 millions de noms de domaine enregistrés dans le monde et seuls 3,7 millions de domaines ont déployé DANE (environ 1 %).

Si nous regardons les plus grands fournisseurs de messagerie, nous constatons que Gmail a déployé MTA-STS mais n'a pas encore déployé DANE ni même DNSSEC.

De même, Microsoft a déployé MTA-STS sur Exchange Online cette année et a annoncé son intention d'offrir DANE à l'avenir, mais il faudra probablement encore quelques années avant de le prendre en charge à la fois sortant et entrant.