Traduction de l’article : https://techcommunity.microsoft.com/t5/exchange-team-blog/introducing-mta-sts-for-exchange-online/ba-p/3106386
Le protocole SMTP n’est pas sécurisé et n’a pas été conçu pour l’être. Les courriels envoyés aux premiers jours d’Internet étaient l’équivalent numérique de l’envoi d’une carte postale par le système postal. Par la suite, le cryptage TLS (Transport Layer Security) a été ajouté pour protéger les communications SMTP. Mais pour maintenir la compatibilité ascendante, il n’a jamais été rendu obligatoire et, aujourd’hui encore, il n’est utilisé que de manière opportuniste par les expéditeurs.
TLS utilise des certificats pour le cryptage, mais ils ne sont pas utilisés pour vérifier l’identité du serveur de destination. Cela expose les connexions SMTP à la falsification du DNS qui peut rediriger les connexions vers le serveur d’un attaquant. Les expéditeurs n’ont aucun moyen de confirmer que le serveur de destination est le serveur de messagerie prévu. Pire encore, après avoir intercepté le trafic, un attaquant avisé peut le relayer vers la destination prévue, et ni l’expéditeur ni le destinataire ne sauront qu’une attaque man-in-the-middle a eu lieu.
La norme SMTP MTA Strict Transport Security (MTA-STS) a été élaborée pour garantir l’utilisation systématique de TLS et pour permettre aux serveurs expéditeurs de refuser de transmettre des messages à des serveurs qui ne prennent pas en charge TLS et ne disposent pas d’un certificat de confiance. La norme MTA-STS a été développée par plusieurs entreprises du secteur de la messagerie électronique réunies par le Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG). Nous avons validé notre mise en œuvre et nous avons maintenant le plaisir d’annoncer la prise en charge de MTA-STS pour tous les messages sortants d’Exchange Online.
Protection des messages sortants
Tout le trafic de messagerie sortant d’Exchange Online est couvert par cette nouvelle fonction de sécurité, et les administrateurs n’ont rien à faire pour l’exploiter. Notre implémentation sortante respecte les souhaits des propriétaires de domaines destinataires via leur politique MTA-STS. MTA-STS fait désormais partie de l’infrastructure de sécurité d’Exchange Online, et il est toujours actif (comme les autres fonctions SMTP de base).
Protection des flux entrants
Rien de nouveau n’est nécessaire dans Exchange Online pour tirer parti de la protection MTA-STS pour vos propres domaines. Exchange Online prend en charge TLS1.2 et offre les certificats TLS requis par la norme. En tant que propriétaires de domaines, nous avons sécurisé plusieurs de nos propres domaines, y compris des domaines primaires tels que outlook.com, hotmail.com et live.com. Par conséquent, nous sommes désormais assurés que les connexions des expéditeurs qui prennent en charge MTA-STS sont bien mieux protégées contre les attaques de type « man-in-the-middle ». Si un expéditeur n’effectue pas les validations MTA-STS, le courriel sera tout de même livré normalement, et TLS sera utilisé si l’expéditeur choisit de l’utiliser.
REMARQUE : Les messages seront délivrés lorsqu’une seule partie prend en charge MTA-STS. Par exemple, lorsqu’un domaine protégé par MTA-STS reçoit un message d’un domaine expéditeur qui ne prend pas en charge MTA-STS, le message est remis. Le message est également remis lorsque le domaine destinataire ne prend pas en charge MTA-STS, mais que le domaine expéditeur le fait. Le seul scénario où les messages ne sont pas remis est celui où les deux parties utilisent MTA-STS et où la validation MTA-STS échoue.
Comment adopter MTA-STS
MTA-STS permet à un domaine de déclarer la prise en charge de TLS et de communiquer l’enregistrement MX et le certificat de destination à attendre. Il indique également ce qu’un serveur d’envoi doit faire en cas de problème. Cela se fait par la combinaison d’un enregistrement DNS TXT et d’un fichier de politique publié sous forme de page Web HTTPS. La politique protégée par HTTPS introduit une autre protection de sécurité que les attaquants doivent surmonter.
L’enregistrement TXT MTA-STS d’un domaine indique le support MTA-STS à un expéditeur, après quoi la politique MTA-STS du domaine basée sur HTTPS est récupérée par l’expéditeur. L’enregistrement TXT suivant est un exemple qui déclare la prise en charge de MTA-STS :
_mta-sts.contoso.com. 3600 IN TXT v=STSv1 ; id=20211201000000Z ;
La politique MTA-STS d’un domaine se trouve à une URL prédéfinie, hébergée par l’infrastructure Web du domaine. La syntaxe de l’URL est https://mta-sts.<nom du domaine>/.well-known/mta-sts.txt. Par exemple, la politique de Microsoft.com se trouve à : https://mta-sts.microsoft.com/.well-known/mta-sts.txt
- version : STSv1
- mode : enforcer
- mx : *.mail.protection.outlook.com
- max_age : 604800
Tous les clients dont les enregistrements MX pointent directement vers Exchange Online peuvent spécifier dans leur propre politique les mêmes valeurs que celles indiquées ci-dessus dans la politique de microsoft.com. L’information unique et requise dans la politique est l’enregistrement MX qui pointe vers Exchange Online (*.mail.protection.outlook.com), et le même certificat est partagé par tous les clients d’Exchange Online.
Pour être protégé par MTA-STS, le propriétaire d’un domaine doit créer l’enregistrement de domaine DNS TXT et héberger le fichier de politique à l’URL HTTPS requise avec un certificat valide qui contient son domaine. Des détails sur MTA-STS sont disponibles dans la RFC 8461.
Rester informé grâce aux rapports TLS-RPT
MTA-STS s’accompagne d’une spécification industrielle extrêmement utile qui décrit un mécanisme standard permettant aux services de messagerie de signaler les problèmes d’envoi qui se produisent lors d’un envoi vers un domaine spécifique. C’est la première fois qu’un canal est disponible pour les propriétaires de domaines afin d’obtenir des rapports directs sur les problèmes réels rencontrés par les expéditeurs lors de l’envoi d’e-mails vers le domaine. Ce mécanisme de rapport peut éviter que les expéditeurs aient à signaler les problèmes liés à l’envoi d’e-mails à votre domaine.
La norme TLS-RPT fournit des rapports pour MTA-STS (et DANE pour SMTP) avec un seul rapport quotidien de chaque service de messagerie qui le prend en charge. Pour recevoir les rapports TLS-RPT, le propriétaire d’un domaine peut créer une entrée DNS TXT pour indiquer où il souhaite recevoir les rapports. Pour la plupart des administrateurs, cela signifie envoyer les rapports à une adresse e-mail, comme le montre l’exemple suivant :
- Exemple d’enregistrement TXT : _smtp._tls.exemple.com. 3600 IN TXT TLSRPTv1;rua=mailto:reports@example.com
Les services de messagerie qui envoient des e-mails à votre domaine et qui prennent en charge à la fois MTA-STS et TLS-RPT envoient des rapports quotidiens à l’adresse e-mail fournie. Des détails sur TLS-RPT sont disponibles dans cette RFC 8460. Microsoft a commencé à envoyer des rapports TLS-RPT aux domaines qui en ont fait la demande.
Échecs de MTA-STS
Si une vérification MTA-STS échoue et que la politique du domaine est configurée pour l’appliquer, un NDR sera généré et le message ne sera pas envoyé. La liste suivante décrit les erreurs qui peuvent se produire en raison d’échecs MTA-STS :
Le serveur de destination ne prend pas en charge TLS
551 5.7.4 STARTTLS est requis par la politique MTA-STS du domaine destinataire.
Le serveur de destination ne prend pas en charge TLS 1.2 ou supérieur
551 5.7.6 MTA-STS requiert TLS 1.2 ou supérieur. Version TLS : <Version TLS observée>
L’enregistrement MX du domaine a échoué à la validation MTA-STS
551 5.4.8 La validation MTA-STS des hôtes MX de ‘<Domaine>’ a échoué.
Le certificat de la destination doit contenir le nom d’hôte dans l’enregistrement MX.
551 5.7.5 Le certificat distant DOIT avoir un nom alternatif de sujet correspondant au nom d’hôte (MTA-STS).
Le certificat de la destination a échoué à la validation
551 5.7.5 Le certificat distant a échoué à la validation MTA-STS. Raison : <Raison>
Implémentation
Nous essayons de respecter les RFCs au mieux de nos capacités. L’objectif est d’obtenir la meilleure interopérabilité possible. Dans un petit nombre de scénarios, il peut y avoir un comportement inattendu, et nous ferons de notre mieux pour documenter ce comportement.
Par exemple, une différence de comportement concerne les enregistrements CNAME et les enregistrements MX. Le fait d’avoir un enregistrement CNAME pour un enregistrement MX n’est pas conforme à la RFC SMTP, mais dans l’intérêt de l’envoi des e-mails de nos clients, nous résolvons actuellement les CNAME vers les serveurs vers lesquels ils pointent pour la livraison des messages. Pour MTA-STS, nous avons adopté une approche plus stricte de la prise en charge de la RFC. Nous ne prenons pas en charge les CNAME lorsque MTA-STS est utilisé. Si un domaine utilise un CNAME et respecte la RFC MTA-STS, ce domaine échouera à nos vérifications MTA-STS et ne recevra pas d’e-mails de notre part. Cependant, il est possible pour un domaine d’inclure le serveur final dans sa politique MTA-STS et de passer nos contrôles MTA-STS, même si cela ne suit pas strictement la RFC MTA-STS.
MTA-STS Vs SMTP DANE :
MTA-STS est né de la lenteur du déploiement de DNSSEC pour protéger les enregistrements DNS associés au SMTP. MTA-STS peut être considéré comme un mécanisme plus léger pour sécuriser votre flux de courrier. Bien que MTA-STS offre une mise à niveau indispensable des protections SMTP actuelles, DANE pour SMTP (avec la prise en charge de DNSSEC) est la référence en matière de sécurisation des connexions SMTP. Cependant, de nombreux clients pourraient trouver que MTA-STS est suffisant pour leurs besoins de sécurité.
Nous avons travaillé sur la prise en charge de MTA-STS et de DANE pour SMTP. Au minimum, nous encourageons les clients à sécuriser leurs domaines avec MTA-STS. Vous pouvez utiliser les deux standards sur le même domaine en même temps, donc les clients sont libres d’utiliser les deux quand Exchange Online offrira une protection entrante utilisant DANE pour SMTP d’ici la fin de 2022. En prenant en charge les deux normes, vous pouvez tenir compte des expéditeurs qui ne prennent en charge qu’une seule méthode.
Les normes MTA-STS et DANE doivent être adoptées par les propriétaires de domaines du côté des destinataires et des services/serveurs qui envoient des courriers électroniques. Nous encourageons vivement tout le monde à adopter ces normes afin d’améliorer la sécurité globale des connexions SMTP. Actuellement, nous validons avec succès les connexions de plus de 35 000 domaines protégés par MTA-STS, et ce nombre augmente chaque mois.
Travaux futurs :
Nous travaillons activement sur des fonctionnalités liées aux normes MTA-STS et DANE pour SMTP, dans le but de permettre à nos clients d’en tirer le meilleur parti. Nous annoncerons ces fonctionnalités dès qu’elles seront disponibles.
Travailler ensemble 