Pourquoi chaque réglage de messagerie doit être correct

Chaque nom que votre machine a résolu aujourd’hui, elle l’a cru, et j’ai écrit tout un article là-dessus. Celui-ci parle de ce qui arrive au courrier après la résolution. En résumé : il est envoyé vers un serveur choisi par le DNS, sur un canal qui n’est chiffré que si personne ne s’y oppose, porteur d’un message que n’importe qui sur le chemin peut lire et modifier, et presque aucune des protections inventées pour empêcher cela n’est activée.

Ce n’est pas une seule chose cassée. C’en est sept, chacune conçue pour que, lorsqu’elle est mauvaise, le courrier passe quand même. Aucune erreur. La facture arrive. La réinitialisation de mot de passe arrive. Simplement, elles arrivent aussi chez, ou à travers, quelqu’un qui n’aurait jamais dû les voir, et rien, nulle part, ne le signale.

Cet article défend l’idée de rendre correct chacun de ces réglages, avec les preuves de ce que chacun vaut. Les trois articles qui le suivent le construisent sur de vrais serveurs : Postfix, Microsoft 365 et Stalwart. Celui-ci dit pourquoi.

L’attaque que la norme décrit puis interdit

Commençons par le tuyau entre deux serveurs de messagerie, parce que c’est celui que la plupart des gens croient déjà réglé. STARTTLS est la commande qui fait passer une connexion SMTP en TLS. La plupart des serveurs de messagerie la prennent en charge, la plupart du courrier est chiffré en transit, et cela ressemble à un problème résolu jusqu’à ce que vous lisiez comment la mise à niveau est proposée.

Le serveur destinataire annonce STARTTLS dans sa salutation. Le serveur émetteur voit l’offre et la prend. Rien ne signe cette offre, et rien ne la protège. Alors une machine sur le chemin entre les deux peut supprimer la ligne, et voici le résultat, capturé en labo depuis un émetteur réglé sur le comportement opportuniste ordinaire par défaut :

 ~> EHLO client.test
[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
 -> Please pay invoice 1042 to sort code 20-00-00, account 12345678.
<-  250 2.0.0 Ok: queued as D6A84132069C

L’émetteur n’a pas vu STARTTLS proposé, alors il a fait ce que veut dire opportuniste : il a envoyé quand même, en clair. La machine au milieu a tout lu, facture et coordonnées bancaires comprises. Le courrier a été remis. Aucune erreur n’est parvenue à personne.

Je n’ai pas inventé cette attaque. La RFC 3207, la norme qui définit STARTTLS, la décrit précisément dans ses propres Security Considerations :

A man-in-the-middle attack can be launched by deleting the “250 STARTTLS” response from the server. This would cause the client not to try to start a TLS session.¹

La même section donne la défense, et c’est l’évidente : pouvoir exiger TLS. “both clients and servers MUST be able to be configured to require successful TLS negotiation … for selected hosts before messages can be successfully transferred.”¹ Alors configurez le destinataire pour qu’il l’exige, et la session dépouillée est refusée :

[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
<** 530 5.7.0 Must issue a STARTTLS command first

Sauf que vous ne le pouvez pas, pas sur un MX public, parce que la même norme l’interdit :

A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.²

Lisez ces deux citations ensemble. La norme décrit une attaque de l’homme du milieu, vous dit que la défense est d’exiger TLS, puis vous dit que votre serveur de messagerie public n’a pas le droit de l’exiger. Relisez-le. Cette règle a été écrite en 2002 pour garder le courrier en mouvement entre des serveurs qui ne savaient pas tous encore faire du TLS. Elle est toujours en vigueur, et c’est pourquoi la majeure partie d’Internet accepte encore le courrier en clair, et pourquoi dépouiller STARTTLS fonctionne encore aujourd’hui.

Il existe aussi une version compétente de l’attaquant. Un destinataire qui exige TLS ne vous sauve pas, parce que l’attaquant n’est pas obligé de retransmettre la session en clair. Il peut lire le texte en clair rétrogradé de l’émetteur et ouvrir sa propre connexion TLS parfaitement valide vers le destinataire, qui voit un bon certificat et s’en satisfait. J’ai montré les deux moitiés en labo : le dépouillement qui expose l’émetteur, et un simple client TLS que le destinataire strict accepte sans broncher. La politique du destinataire ne peut pas arrêter cela. Seul l’émetteur qui refuse d’envoyer sans TLS authentifié l’arrête, et c’est tout l’argument en faveur de DANE³ et de MTA-STS,⁴ qui viennent plus loin dans cet article.

Sept réglages, et comment chacun échoue en laissant passer

Le tuyau est l’un des deux problèmes. L’autre, c’est l’identité : un message qui arrive chiffré ne fait toujours que prétendre venir de celui qu’il annonce. Il y a donc sept réglages en jeu, répartis sur ces deux tâches, et ce qu’ils ont en commun est ce qu’il vaut mieux apprendre en premier.

Voici chacun d’eux : ce qu’il protège, et ce qu’il fait quand il est mal réglé. Regardez la dernière colonne. Presque toujours, elle dit que le courrier part quand même.

Six de ces sept, mal réglés, remettent quand même le courrier. DANE est l’exception. C’est le seul réglage de toute la liste qui échoue en bloquant : ratez-le et votre courrier s’arrête au lieu de fuir. Gardez cette idée, car c’est précisément la raison pour laquelle les gens en ont peur, et la raison pour laquelle c’est celui qui vaut le plus.

Un mot sur chacun des trois de l’identité, car le reste de cette série s’appuie dessus. SPF liste les serveurs autorisés à émettre pour un domaine, et se termine par une règle : -all veut dire « personne d’autre », ~all veut dire « personne d’autre, mais remets-le quand même ». DKIM ajoute une signature cryptographique sur le message, de sorte que tout changement se voit, du moment que le domaine a bien publié une clé pour la vérifier. DMARC relie les deux et dit au destinataire quoi faire quand ils échouent, et s’ils concordent avec l’adresse From: que le lecteur voit réellement. Ce sont les RFC 7208, 6376 et 7489, et chacune mérite son propre article.^{6 7 8}

DMARC seul laisse passer une facture trafiquée

La couche d’identité a un trou exactement là où il coûte le plus cher, et cela vaut la peine d’être montré parce que « nous avons DMARC en reject » est ce que les gens disent quand ils se croient couverts.

DMARC réussit si SPF ou DKIM réussit et concorde avec le domaine From:. L’un ou l’autre, pas les deux. Alors prenez un vrai message signé d’un domaine, changez les coordonnées bancaires dans le corps, et renvoyez-le depuis le même endroit :

SPF réussit toujours, parce que le message vient d’un serveur autorisé. La signature DKIM échoue désormais, parce que le corps a été modifié. Mais DMARC n’a besoin que d’une seule réussite alignée, et SPF lui en a donné une, donc DMARC réussit et le message au nouveau numéro de compte est remis en ressemblant exactement à l’original. Je l’ai capturé en labo : Rspamd lui a attribué R_SPF_ALLOW, R_DKIM_REJECT et DMARC_POLICY_ALLOW, et à lui seul il l’aurait remis. La seule chose qui l’a arrêté était une règle qui rejette d’emblée sur une signature cassée. Un domaine en p=reject n’est pas protégé contre le trafiquage que cette signature était censée détecter. Cela vaut la peine de le savoir avant de considérer le travail terminé.

DANE ne vaut que le DNSSEC qui est en dessous

Passons maintenant aux réglages de transport qui arrêtent vraiment l’attaquant compétent, parce qu’ils déplacent la décision vers l’émetteur. DANE est le plus fort d’entre eux. Il permet à un domaine de publier, dans le DNS, une empreinte de la clé que son serveur de messagerie présentera, dans un enregistrement TLSA, pour qu’un serveur émetteur puisse refuser tout ce qui ne correspond pas.⁹ Aucune autorité de certification impliquée, aucune confiance accordée à celui qui a répondu à la poignée de main TLS. Le propriétaire du domaine dit « voici ma clé », et c’est tout.

Sauf que les réponses DNS sont falsifiables, donc une empreinte publiée dans du DNS ordinaire ne vaut rien : le même attaquant qui dépouille STARTTLS peut vous tendre une fausse empreinte correspondant à une fausse clé. DANE ne signifie quelque chose que lorsque le DNS où il réside est signé avec DNSSEC, pour que l’empreinte elle-même ne puisse pas être falsifiée. Voilà toute la chaîne, et c’est pourquoi cet article s’inscrit dans une série qui a commencé par DNSSEC. Si vous ne l’avez pas rencontré, les bases sont dans /fr/dns/dnssec-the-root-is-signed-you-are-not/, et la version en une ligne est : la racine est signée, chaque TLD digne de ce nom est signé, puis cela s’arrête net aux noms que les gens utilisent vraiment.

Le schéma montre deux domaines qui publient tous deux un enregistrement TLSA. L’un se trouve dans une zone signée, avec une chaîne de signatures ininterrompue de la racine jusqu’à l’empreinte, de sorte qu’un émetteur peut lui faire confiance. L’autre se trouve dans une zone non signée, donc son empreinte n’est que des octets que n’importe qui aurait pu écrire, et un émetteur correct l’ignore entièrement et n’obtient aucune protection DANE du tout. Même enregistrement, publié de deux façons. Une seule des deux peut prouver qu’elle est authentique.

L’enregistrement à publier est 3 1 1 : la clé propre du serveur plutôt que celle d’une AC, la clé publique plutôt que le certificat entier, hachée en SHA-256. Le chiffre du milieu est celui qui paie à l’usage, parce qu’épingler la clé plutôt que le certificat signifie que l’enregistrement survit à chaque renouvellement tant que vous gardez la même clé. L’article Postfix donne la procédure complète et le piège qui attrape les gens, à savoir que la manière habituelle de renouveler les certificats fabrique une nouvelle clé à chaque fois et casse l’enregistrement en silence. Ici, ce qu’il faut retenir, c’est que 3 1 1 plus la réutilisation de la clé est un enregistrement que vous publiez une fois et laissez tranquille.

Les règles de la maison, et ce que chacune coûte

Tout ce qui précède se résume à une courte liste de règles, et les trois articles suivants y soumettent de vrais serveurs. Elles ne sont pas édulcorées, et elles ne sont pas gratuites. Les voici avec la facture jointe, parce qu’une règle dont vous cachez le coût est une règle que vous n’avez pas vraiment décidé de tenir.

Le coût de la redirection est celui qui mord, et il est réel : rejetez sur le seul SPF et un message redirigé depuis un endroit absent de l’enregistrement SPF de l’émetteur est refusé, parce que, pour le destinataire, un redirecteur ressemble exactement à un faussaire. Il existe des correctifs, SRS et ARC,¹⁰ et l’article Postfix montre l’échec. La position honnête est que ces règles rejettent du courrier qu’un serveur plus laxiste aurait remis. C’est bien le but. Une partie de ce courrier aurait dû être rejetée, et le reste vous renseigne sur une configuration de redirection qui comptait sur le fait que personne ne vérifie.

Ça échoue en laissant passer, et en voici la preuve

L’affirmation sur laquelle repose tout cet article est que ces réglages échouent en laissant passer, en silence, de sorte que vous ne pouvez pas distinguer, en regardant, un réglage qui marche d’un réglage cassé. Ce n’est pas une inquiétude théorique. En montant le serveur Postfix pour l’article suivant, chacun de ces échecs s’est produit, et chacun était un réglage qui semblait configuré et ne faisait rien.

Six réglages réels, chacun issu du montage du serveur Postfix pour l’article suivant. Cinq ont échoué en laissant passer : ils ont remis le courrier, sans erreur, avec toutes les apparences d’un fonctionnement correct. Le sixième, l’enregistrement DANE périmé, a échoué en bloquant. C’est celui que tout le monde redoute, et c’est le seul qui a protégé le message au lieu de le laisser fuir. La leçon est là, dans la dernière colonne du schéma : le réglage que les gens évitent parce qu’il pourrait arrêter leur courrier est le seul qui se comporte comme un contrôle de sécurité est censé le faire.

Chaque ligne de cela est une capture, pas une lecture de manuel. La façon de distinguer un réglage qui marche d’un réglage cassé est d’envoyer le message qu’il est censé arrêter et de regarder ce qui revient, et je le dis une fois ici et le prouve trois fois dans le reste de la série.

Alors, qui fait vraiment quoi que ce soit de tout ça ?

C’est une chose de dire que les réglages comptent. C’en est une autre de demander si les organisations dont le courrier compte le plus les ont activés. Alors je l’ai fait, avec rien d’autre que du DNS en lecture seule et un résolveur validant, le 22 octobre 2026 : vingt-six domaines qui reçoivent du courrier, les banques, les grands fournisseurs, les spécialistes allemands et les autorités de certification, chacun vérifié pour les sept choses de cet article.¹¹

Lisez d’abord la colonne DMARC, parce que c’est celle qui est la plus remplie. La plupart de ces domaines publient une politique DMARC, et la plupart des banques sont en reject. DMARC est le réglage qui se fait, parce que c’est celui qu’un auditeur réclame et celui qu’un fournisseur peut vous vendre, et il est visible : vous pouvez le consulter et cocher une case. C’est aussi, à lui seul, le réglage qui a laissé passer une facture trafiquée plus tôt dans cet article.

Lisez maintenant la colonne DANE, le seul réglage ici qui ne peut être ni rétrogradé ni falsifié. Cinq domaines sur vingt-six. Chacun d’eux est un fournisseur allemand ou Proton. Pas une seule banque britannique. Pas une seule des autorités de certification, les entreprises dont tout le métier est de se porter garant des clés. La plus forte protection contre l’attaque précise par laquelle cet article a commencé est assurée par une poignée de gens qui s’en soucient, et par personne qui ne soit simplement conforme.

Les banques sont la ligne la plus tranchante. Huit d’entre elles, toutes en DMARC reject, et entre elles : aucun DANE, aucun MTA-STS imposé, et une seule, Monzo, joignable en IPv6. Deux des quatre autorités de certification ne publient aucun enregistrement SPF à leur propre apex. HMRC et NatWest n’en ont pas non plus. Ce ne sont pas de petites structures qui ne s’y sont jamais mises. Ce sont les organisations qui vous envoient le courrier dont vous craignez le plus la falsification, et la protection qu’elles ont est le badge qui paraît le plus solide et fait le moins.

La colonne IPv6 est un petit scandale à elle seule. Vingt des vingt-six n’ont aucun enregistrement AAAA sur leur serveur de messagerie, de sorte qu’un émetteur fonctionnant sur un réseau IPv6 uniquement ne peut pas les joindre, et ce nombre ne va que dans un sens. J’ai écrit /fr/networking/we-never-ran-out-of-addresses/ sur le refus de l’industrie de finir ce travail, et le revoici, dans le chemin du courrier cette fois. C’est la même forme que le recensement gov.uk dans /fr/dns/dnssec-the-root-is-signed-you-are-not/ : la partie difficile a été faite il y a des années, les registres la donnent, et les gens qui devraient le plus manifestement l’utiliser ne l’ont pas fait. Le gov.uk central n’est même pas dans le tableau, parce qu’il ne publie aucun MX. Il ne reçoit pas de courrier. C’est une façon de réussir le test.

Si vous ne le faites toujours pas, pouvez-vous vous dire professionnel ?

Chaque norme nommée dans cet article, et le recensement qui la soutient, pointent dans une seule direction : ce n’est pas un problème de recherche, c’est un problème d’activation, et l’activation n’est pas faite par les gens les mieux placés pour la faire. Quand les preuves penchent à ce point, la question cesse d’être théorique et devient une question à laquelle vous devez répondre au sujet de vos propres serveurs. Si vous faites tourner la messagerie d’une organisation qui gère l’argent d’autrui ou la santé d’autrui, et que votre MX ne fait aucun DANE, n’impose aucun MTA-STS et ne peut être joint en IPv6, pouvez-vous appeler cela un travail professionnel ?

Il y a trois réponses honnêtes, et seules les deux premières tiennent. Oui, avec une raison écrite et une date en face : vous êtes sur une plateforme qui ne propose pas encore DANE, vous l’avez signalé, et il y a une ligne dans le plan de l’an prochain. C’est un professionnel qui gère une vraie contrainte, et c’est très bien. Oui, parce que vous ne saviez pas, et maintenant vous savez, et vous allez aller voir où en est votre serveur cette semaine. Personne n’a commencé en sachant cela. Et non : vous en saviez assez pour être mal à l’aise, vous avez lu jusqu’ici, et vous allez fermer l’onglet et ne rien changer, parce que le courrier circule, qu’aucune erreur n’est levée et que personne ne vous y oblige. Celle-là n’est pas une lacune de connaissance. C’est une décision de laisser cassé ce dont vous êtes responsable, parce que cassé est plus tranquille.

La norme ne vous oblige pas à le faire. C’est tout le problème, et c’est aussi tout l’enjeu. Savoir n’est pas quelque chose qui vous arrive, et personne ne va venir vous dire que votre serveur de messagerie envoie tranquillement en clair depuis deux ans. De ce fait, s’assurer de savoir est le travail, et il n’est celui de personne d’autre.

Une norme est une promesse qu’on tient quand personne ne regarde

Les morceaux de tout cela ont été achevés il y a des années. STARTTLS date de 2002, SPF, DKIM et DMARC ont dix ans ou plus, DANE pour le courrier a été spécifié en 2015, MTA-STS en 2018. Rien de tout cela n’est derrière une licence, rien n’exige de fournisseur, et les registres qui porteraient les enregistrements DNSSEC les donnent. L’ingénierie difficile est faite. Ce qui reste est la partie facile, celle qui n’est facile que si quelqu’un s’en donne la peine : l’activer, vérifier qu’elle est bien active, et la garder active quand le certificat se renouvelle et que l’enregistrement doit suivre.

Cette dernière partie, c’est tout, en réalité. Une norme n’est pas le document. Le document existe depuis vingt ans et le courrier part encore en clair. Une norme est une chose que vous tenez quand aucun message d’erreur ne vous force à la tenir, quand le courrier circulerait tout pareil si vous la laissiez discrètement tomber, quand la seule personne qui le saurait jamais, c’est vous. Chacun de ces réglages échoue en laissant passer précisément pour que personne ne soit forcé d’y tenir. Ce qui veut dire qu’y tenir est tout le travail.

Vous n’en recevez aucune récompense. La facture qui n’a pas été modifiée ressemble exactement à celle qui l’a été. La réinitialisation de mot de passe que personne n’a lue en transit ressemble exactement à celle que quelqu’un a lue. La seule différence est les jours où quelque chose a essayé, et ces jours-là, la personne qui a tout activé et vérifié que ça marchait ne découvre jamais qu’elle a été attaquée, parce que ça n’a pas marché. Voilà à quoi ressemble un travail bien fait vu de l’extérieur : rien ne se passe, pour des raisons que personne ne peut voir.

Alors réglez quand même chaque paramètre correctement. Pas parce que quelqu’un vérifie, car personne ne le fait. Faites-le parce que c’est vous qui avez dit que le courrier était sûr, et par chez nous, ça compte encore pour quelque chose.