S'il est de plus en plus souvent chiffré pendant son transport et parfois lui-même, l'email n'est pour autant pas conçu comme très sécurisé. Spam, phishing et spoofing sont ainsi encore son quotidien, notre quotidien. Heureusement, il existe des solutions... qu'il faut pouvoir utiliser.
Le saviez-vous : n'importe qui peut envoyer un email depuis l'adresse de son choix. Il est très simple d'envoyer un email avec comme expéditeur bill@gates.com depuis n'importe quel ordinateur connecté à internet. Il suffit pour cela d'avoir accès à un serveur SMTP maison, ou peu regardant. L'origine de nombreux problèmes.
L'envoi sécurisé d'emails, un problème depuis près de 40 ans
SMTP est l'un de ces vieux protocoles des débuts d'Internet. Il n'a guère évolué depuis, si ce n'est pour préciser son implémentation du chiffrement TLS... en 2018. Pour lui, l'adresse de l'expéditeur (from) n'est qu'un champ de texte parmi d'autres, ne nécessitant aucune authentification ou vérification spécifique.
Et quand bien même : un serveur SMTP (ou Mail Transfer Agent, MTA) peut utiliser n'importe quelle adresse d'expéditeur. La mise en place d'une telle sécurité ne permet donc à un service que de se protéger contre les actions malveillantes de ses utilisateurs. Ainsi, lorsque vous vous connectez avec votre compte Google au SMTP de Gmail, c'est pour se protéger que l'entreprise décide que « utilisateur@gmail.com » sera forcément utilisée comme adresse d'expéditeur.
Mais n'importe qui pouvant expédier des emails depuis son propre MTA, comment s'assurer qu'il a le droit d'envoyer un email pour tel ou tel domaine, que cette information est fiable, que le message ou ses en-têtes n'ont pas été modifiés pendant le transport ? Ce, sans avoir à remplacer une brique logicielle telle que SMTP, créé il y a près de 40 ans, à la base de très nombreux outils et services, utilisé au quotidien et aux multiples implémentations.
Ce n'est pas la signature cryptographique des emails qui peut aider ici. Car, même si elle était massivement utilisée (ce qui n'est pas le cas), elle ne permettrait que de certifier qu'un message n'a pas été modifié et a bien été envoyé par un utilisateur détenant une clé privée. Aucune assurance qu'il est bien le propriétaire d'un domaine ou d'une adresse email.
Heureusement, des solutions ont été trouvées sous forme d'acronymes, reposant en partie sur ce bon vieux DNS : SPF, DKIM, (DM)ARC et BIMI. Vous n'en avez jamais entendu parler ? Vous n'êtes pas les seuls...
SPF : qui peut faire quoi ?
SPF a été défini il y a une quinzaine d'années pour apporter une première solution à la lutte contre l'usurpation d'identité (spoofing). Elle est donc le plus souvent mise en place par les hébergeurs et fournisseurs de services. Il reste néanmoins nécessaire de vérifier que c'est bien le cas et que la règle énoncée correspond à ce que vous désirez.
Le Sender Policy Framework (SPF) permet de déclarer quels serveurs peuvent expédier des emails pour chacun de vos domaines et quoi faire en cas d'erreur. Ainsi, lorsqu'un utilisateur recevra un email depuis l'un de vos domaines dans l'adresse de l'expéditeur, son MTA pourra très facilement vérifier qu'il vient d'un serveur autorisé et aura une indication de la marche à suivre dans le cas contraire. Il reste néanmoins maître de sa décision (nous en reparlerons).
SPF prend la forme d'un enregistrement DNS de type TXT, lisible avec une simple commande dig ou nslookup. Par exemple, pour le domaine de Stéphane Bortzmeyer, qui a analysé la RFC 7208 détaillant la procédure :
nslookup -type=txt bortzmeyer.fr
On obtient le résultat suivant :
text = "v=spf1 mx -all"
Il signifie que tous les serveurs indiqués dans les enregistrements DNS de type MX du domaine (ceux utilisés pour la réception d'emails) peuvent en envoyer. Tous les autres doivent être rejetés, un choix symbolisé par le « - ». Il se fait parmi quatre possibilités, nommées qualifieurs. Ils sont présentés ainsi par Google :
- Validé (rien ou +) : Si l'e-mail provient d'un serveur qui correspond à un mécanisme doté du qualifieur « + » (ou sans qualifieur), il est validé. Le destinataire doit accepter l'e-mail.
- Échec (-) : Si l'e-mail provient d'un serveur qui correspond à un mécanisme doté du qualifieur « - », il est mis en échec. Le destinataire doit rejeter l'e-mail.
- Échec partiel (~) : Si l'e-mail provient d'un serveur qui correspond à un mécanisme doté du qualifieur « ~ », il est validé, mais considéré comme suspect.
- Neutre (?) : Les mécanismes dotés du qualifieur « ? » n'ont pas d'incidence sur la validation de l'e-mail.
Certains domaines renvoient une réponse avec un indicateur de version différent, comme ici :
v=spf2.0/pra
Il correspond à la norme Sender ID, un temps défendue par Microsoft, mais tombée en désuétude depuis.
Attention : un seul enregistrement est toléré par domaine, mais il peut être composé de manière plus ou moins complexe, avec plusieurs IPv4 ou IPv6, domaines, etc. Il est néanmoins conseillé de garder une déclaration simple. Vous rencontrerez parfois dans la réponse le mécanisme include, comme chez OVH, Gandi ou divers services en ligne :
text = "v=spf1 include:mx.ovh.com ~all"
text = "v=spf1 include:_mailcust.gandi.net ?all"
Il signifie que les paramètres SPF à utiliser sont ceux du domaine « inclus ». Par exemple pour mx.ovh.com :
text = "v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all"
Cette solution permet aux services de transmettre un paramètre simple à leurs clients, tout en utilisant une variable plus complexe en réalité, qu'ils pourront faire évoluer quand bon leur semble, selon leurs besoins.
DKIM : la cryptographie à la rescousse
SPF est un enregistrement DNS indiquant une liste de serveur considérés comme conformes. Mais comment assurer que le message l'est également ? C'est le rôle de DomainKeys Identified Mail (DKIM).
Comme son nom l'indique, il s'agit d'une mécanique d'authentification du domaine exploitant du chiffrement asymétrique. Ce n'est pas un remplaçant de SPF, mais plutôt un complément, accompagnant tout message sortant d'une signature numérique (dans son en-tête), générée depuis un couple de clés publique/privée liées au domaine.
Cela permet non seulement de vérifier que le message a bien été envoyé depuis le domaine de l'expéditeur annoncé, mais également qu'il n'a pas été modifié pendant son transport. Une double assurance bienvenue. En complément de SPF, DKIM doit permettre aux MTA de déterminer si un message doit être considéré ou non comme du spam.
Mais il n'est presque jamais exposé à l'utilisateur, peu de clients email affichant le statut SPF ou DKIM d'un message reçu. Google le fait dans Gmail depuis quelques années. Il existe également une extension Thunderbird trop peu connue pour cela. Des services tiers existent également come Mail Tester ou MX Toolbox. Vous pouvez enfin regarder les en-têtes des emails si votre client le permet, ici Outlook (Fichier > Propriété du message) :
Si vous recevez un email d'un abonné Orange, il ne passera ni le test SPF, ni DKIM. Bienvenue en 2020 !
Une solution parfaite ? Eh bien non. Car si DKIM est entré dans les mœurs des grandes plateformes/entreprises et autres institutions, il est loin d'être généralisé, surtout chez de plus petits acteurs ou dans le service proposé au client.
(DM)ARC : que faire des mails reçus, mais mal identifiés ?
Vous savez désormais comment indiquer qu'un serveur est autorisé à envoyer des emails depuis votre domaine, comment ajouter une signature numérique dans l'en-tête de vos messages pour vérifier leur destinataire et assurer qu'ils n'ont pas été modifiés. Mais lorsque vous recevez des emails, comment prendre ces signaux en compte ?
C'est le rôle du protocole Domain-based Message Authentication, Reporting and Conformance (DMARC), permettant d'indiquer quoi faire lorsqu'un email ne passe les tests SPF et DKIM. Ou lorsque les domaines des deux tests ne sont pas « alignés » (identiques ou sous-domaine l'un de l'autre). Vous avez alors trois possibilités :
- Rejeter (
Reject) - Ne rien faire (
none) - Considérer comme suspect (
quarantine)
Précision : dans le cas de la politique none, il sera précisé que l'email n'a pas passé le test, mais aucune action n'est demandée. La suspicion n'entraîne également pas d'action systématique, tout dépendra du MTA du destinataire et de son filtre anti-spam. Seul cas où la sentence est directe, presque irrévocable : le rejet.
La diffusion de cette politique prend à nouveau la forme d'un enregistrement DNS de type TXT. Cette fois, elle correspond au sous-domaine _dmarc. du domaine concerné. Par exemple dans le cas du service d'emails de Microsoft :
nslookup -type=txt _dmarc.outlook.com
On obtient le résultat suivant :
"v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"
Comme pour SPF, on a tout d'abord un indicateur de version (DMARC1), puis un autre paramètre obligatoire (p). Les autres sont facultatifs, détaillés dans le point 6.3 de la RFC 7489. Pour ceux présents ci-dessus :
- p : politique à suivre pour le domaine principal
- sp : politique à suivre pour les sous-domaines
- pct : pourcentage d'emails concernés par l'analyse DMARC (100 par défaut)
- rua : adresse à laquelle envoyer les rapports agregés de DMARC
- ruf : adresse à laquelle envoyer les rapports d'erreur individuels
- fo : configuration du rapport DMARC
Notez la possibilité de recevoir des rapports, qui peut être intéressante pour savoir qui exploite votre domaine de manière non désirée. Même si vous avez une politique ouverte (none), c'est un élément intéressant pour agir en cas d'abus.
Pourtant et contrairement à SPF, la précision d'une politique via DMARC est encore trop rare. Elle peut d'ailleurs poser problème. Le cas AOL/Yahoo est l'un des plus connus : en 2014, l'entreprise a du jour au lendemain décidé d'indiquer que tous les emails jugés non conformes devaient être rejetés. Un choix qui n'a pas changé depuis :
"v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;"
De quoi perturber de nombreux services qui recevaient des emails d'utilisateurs AOL/Yahoo, SPF et DKIM étant des solutions imparfaites. Notamment en cas de redirection ou de transmission via une liste de diffusion, qui peuvent renvoyer un résultat négatif pour SPF (expéditeur modifié) ou DKIM (message modifié). Des cas pourtant légitimes.
L'Authenticated Received Chain (ARC) a été imaginée pour répondre à ces problèmes. Il s'agit, lorsqu'un message passe par différents serveurs et intermédiaires, de préserver le résultat des tests DKIM et SPF originaux, tout en constituant une chaîne de confiance au fil des serveurs. Le MTA du destinataire recevra l'ensemble des informations, et pourra choisir s'il accepte ou non de considérer le(s) serveur(s) intermédiaire(s) comme tiers de confiance.
Pour cela, il devra se fier à trois éléments d'en-tête ajoutés à chaque « hop » et numérotés (variable « i ») :
- ARC-Authentication-Results : le statut ARC/DMARC, DKIM et SPF à réception du message
- ARC-Message-Signature : une signature du message à son expédition
- ARC-Seal : une signature des en-têtes ARC au fil de la chaîne
Concernant son support, on se retrouve dans la même situation que DKIM : cela dépendra principalement de la configuration du serveur de mail et donc de votre configuration ou de votre prestataire. Il ne reste donc plus qu'à espérer que le plus grand nombre s'y mette rapidement (plus que pour DKIM...).
BIMI : votre logo illustre vos emails
Dernière initiative en date : Brand Indicators for Message Identification (BIMI). Cette fois, il ne s'agit pas d'ajouter un élément technique invisible à l'utilisateur mais, au contraire, de faire apparaître le logo (carré, SVG) d'une entité dans les clients emails compatibles si un message est considéré comme valide. L'URL est précisée dans un enregistrement DNS.
Par exemple chez Dropbox, avec la requête suivante :
nslookup -type=txt default._bimi.dropbox.com
On obtient :
text = "v=BIMI1; l=https://cfl.dropboxstatic.com/static/images/logo_catalog/dropbox_logo_glyph_m1_bimi.svg;"
Un standard en cours de finition, déjà en cours d'implémentation ici ou là. Il doit être complété par la création de Mark Verifying Authority (MVA) délivrant des certificats (VMC) pour confirmer qu'un logo peut être utilisé par un domaine, à la manière des certificats SSL. Là aussi pour éviter toute usurpation d'identité.
Un processus dont il y a fort à parier qu'il sera payant une fois mis en place.
SPF, DKIM et (DM)ARC ne protègent pas de tout
Comme on l'a vu, les différentes solutions existantes assurent un certain niveau de protection malgré la permissivité intrinsèque de l'email. Ils permettent d'effectuer des vérifications à de nombreux niveaux : autorisation du serveur, légitimité de l'expéditeur, intégrité du message, politiques à appliquer, affichage dans le client, etc.
Pour les grandes plateformes, ils sont autant de signaux à prendre en compte. Si vous ne les fournissez pas, vous avez de grandes chances de terminer dans les spams par défaut ou même d'être rejeté. Mais à l'inverse, ce n'est pas parce que vous avez suivi l'ensemble des instructions à la lettre que vos emails seront forcément considérés comme légitimes. Ou que tous les emails que vous recevrez en tant qu'internaute seront débarrassés de tout message malveillant.
Car c'est la politique anti-spam du MTA qui fait foi. Et celle-ci peut décider de prendre en compte de nombreux autres facteurs, comme la réputation du domaine, des serveurs, des listes d'adresses IP connues pour être malveillantes ou peu regardantes, etc. Voilà pourquoi des emails envoyés par des clients de grands FAI français arriveront à bon port même sans passer les tests DKIM et SPF, alors que votre domaine personnalisé pourra être rejeté s'il n'a que du SPF.
Cela dépendra des acteurs – aucune règle globale n'a été établie, comme l'a montré le cas de la politique de rejet dure via DMARC de Yahoo – et de l'impact que cela peut avoir. Il est ainsi d'autant plus important que les fournisseurs de services d'email s'adaptent au plus vite à ces différentes procédures, en place pour certaines depuis une quinzaine d'années. De quoi réduire les risques pour tout le monde, sans les supprimer.
Car rien n'empêche un acteur malveillant de créer un faux domaine 0range.fr, avec les validations SPF/DKIM/DMARC, pour envoyer de faux formulaires à des clients du FAI et tenter de récupérer leurs identifiants. En l'état, si on ne s'appuyait que sur ces critères, il serait plus légitime qu'un email envoyé par Orange ou ses clients. Un comble !
La vigilance reste de mise, avec toujours le même triptyque :
- Méfiez-vous des emails reçus et regardez-y à deux fois avant de livrer des informations sensibles
- N'hésitez pas à signaler tout comportement malveillant détecté
- Privilégiez des services privilégiant votre sécurité
