Les emails : analyse technique et enjeux de souveraineté

En marge de notre dossier sur le fonctionnement en profondeur d’Internet, nous avons décidé de nous pencher sur les emails. Ils sont utilisés par tout le monde, parfois pour des futilités, parfois pour des choses importantes. Ils constituent aussi un enjeu de souveraineté, malheureusement trop souvent pris à la légère.

• [Dossier] Internet, mode d’emploi : une URL c’est quoi ? (partie 1)

Un email, c’est une carte postale

Un email par défaut, il faut le considérer comme une carte postale : n’importe quel intermédiaire peut lire son contenu, son expéditeur et son destinataire. Pire encore, il est facile d’usurper n’importe quelle identité. On peut évidemment appliquer une couche de chiffrement – un peu à la manière de mettre la carte postale dans une enveloppe –, mais c’est un autre sujet que nous aborderons dans un second temps.

Tout d’abord, comment se passe l’envoi d’un email ? Il faut savoir que l’email se décompose en deux principales parties, regroupées au sein de ce qu’on appelle le format MIME (Multipurpose Internet Mail Extensions ou Extensions multifonctions du courrier Internet) :

• Un en-tête (header) avec l’expéditeur, le destinataire, le sujet, la date…
• Le corps du message (body) avec le contenu de l’email et les éventuelles pièces jointes

La première partie du voyage de notre message se déroule dans un client de messagerie (Mail User Agent ou MUA) de l’expéditeur, que ce soit une application ou depuis un site web. L’acheminement du courrier se fait ensuite vers un serveur de courriel (Mail Transfer Agent ou MTA) rattaché à votre nom de domaine, via le protocole SMTP. À partir de là, la moitié du chemin est faite.

On peut se faire passer pour n’importe qui, la preuve !

L’email passe du serveur MTA lié à votre messagerie au serveur MTA rattaché au nom de domaine de votre destinataire. Par exemple, si vous m’envoyez un email sur une adresse en @next.ink depuis un email @Orange.fr, le serveur MTA de départ sera celui d’Orange, celui de réception est chez moji (qui héberge Next.ink). De son côté, le destinataire récupère son email via son client de messagerie relié au MTA (de moji, vous suivez ?).

Le problème avec cette architecture, c’est qu’il est très facile pour n’importe qui de faire n’importe quoi. En effet, on peut facilement modifier les en-têtes pour changer l’expéditeur et se faire passer pour une autre personne.

N’allez en effet pas croire que c’est compliqué à mettre en place… quelques lignes de codes et une dizaine de minutes suffisent. Pour créer le message ci-dessous, nous avons simplement assemblé un email avec les éléments suivants (oui, c’est aussi simple que ça en a l’air, mais nous ne ferons pas de tuto) avec le résultat juste en dessous :

message = MIMEMultipart()
message["From"]="Sundar Pichai sundar.pichai@google.com"
message["Subject"]="Trop bien guys votre enquete sur les sites GenAI !"
message["Reply-To"]="sundar.pichai@google.com"

Vers qui partent les emails ? Les enregistrements MX balancent tout !

Les mails pouvant circuler dans tous les sens sans restriction particulière par défaut, les serveurs associés aux adresses emails sont publics. On les trouve dans les enregistrements MX des noms de domaines ; MX pour Mail eXchange.

Cette information est publique, dans le DNS, lisible par tout le monde depuis son ordinateur. Deux outils extrêmement simples permettent de récupérer les enregistrements MX : nslookup et dig (il en existe bien d’autres).

Sous Windows et Linux, nslookup est disponible en ligne de commande. Il existe aussi dig, plus complet, sur les distributions Linux. Voici les commandes à utiliser dans les deux cas, pour les serveurs emails recevant tous les envois vers @next.ink. Pour dig, nous avons ajouté le paramètre +short afin de n’avoir que les champs MX les uns en dessous des autres sans tous les détails supplémentaires, mais vous pouvez l’enlever pour une réponse plus longue.

nslookup -type=mx next.ink
dig +short MX next.ink

Dans les deux cas, le résultat est évidemment le même : mx1.oui.do avec une préférence à 1 et mx2.oui.do avec la préférence à 2. La préférence est simplement l’ordre dans lequel il faut choisir les serveurs pour envoyer les emails. mx1.oui.do est le premier, mais s’il ne répond pas, un serveur secondaire est disponible sur mx2.oui.do.

Ce que les enregistrements MX permettent de prouver

Cela signifie donc qu’un simple coup d’œil à l’enregistrement DNS permet de savoir qui s’occupe de la réception des emails. Si une entreprise utilise les services de Google pour gérer ses emails, les enregistrements MX pointeront vers des sous domaines de Google.com. Pour du Microsoft, ils pointent vers du Outlook.com, etc.

Quelques points à savoir. Les serveurs MX indiquent la route à suivre et pointent vers le premier « poste de douane », c’est-à-dire l’endroit où arrivent les emails avant d’être ensuite acheminés vers leur destinataire. Ils peuvent ensuite prendre des chemins plus ou moins long et sinueux avant d’arriver à destination, mais nous n’avons pas accès aux détails des routes, c’est de la tambouille interne.

Voici quelques exemples. Certains comme Polytechnique et l’Université de Paris Saclay gèrent la réception en interne, d’autres comme l’Université de Versailles Saint-Quentin passent par Renater (Réseau National de télécommunications pour la Technologie, l’Enseignement et la Recherche). Blablacar utilise de son côté Google.

Cela ne veut pas obligatoirement dire que les mails @Blablacar.fr finissent dans une boite Gmail ou un compte Google Workspace, mais cela prouve néanmoins qu’ils arrivent chez Google comme premier poste de douane.

Le géant du Net a donc accès à un moment donné à tous les emails envoyés à @Blablacar.fr. Et comme tout poste de douane qui se respecte, il peut décider du jour au lendemain de couper l’accès, mais de continuer à recevoir les emails entrants, jusqu’à ce que les enregistrements MX soient changés.

Autre point important, ce n’est pas parce qu'une entreprise passe par autre chose que Google ou Outlook dans ses enregistrements MX, qu’elle n’utilise pas à un moment donné les services des géants américains ; simplement les enregistrements MX ne permettent pas de le prouver.

Certains comme Shares.io – un outil d’investissement « développé, opéré et régulé en France » – doublent la mise avec Google comme enregistrements MX primaire, secondaire et tertiaire, ainsi que Outlook en quatrième position si les trois serveurs Google devaient ne pas répondre. Ceinture et bretelle aux couleurs des États-Unis en somme.

Un vrai enjeu de souveraineté !

En résumé : si les MX pointent vers Google ou Microsoft, cela prouve que les entreprises américaines ont accès aux emails, peu importe où ils finissent par arriver. Mais nous ne pouvons en déduire rien de plus ; aucun corollaire n'existe à cette affirmation.

Par exemple, les enregistrements MX de Next.ink renvoient vers oui.do, mais ensuite impossible de savoir ce qu’il se passe pour un observateur à l’extérieur ; ils pourraient se retrouver sur un compte Gmail sans que vous le sachiez. Rassurez-vous, chez Next les emails sont bien gérés et stockés en interne chez oui.do (moji), dans leur datacenter à Nanterre.

La gestion des enregistrements MX est donc un enjeu fort quand il s’agit de parler de souveraineté numérique. Problème, beaucoup d’entreprises, start-ups et institutions françaises utilisent encore massivement Google et dans une moindre mesure Microsoft comme point d’entrée des emails.

SPF, DKIM et DMARC : le trio de la sécurité des emails

Terminons enfin avec un point que nous avions déjà abordé il y a quelques années, mais qu’il est bon de rappeler quand on parle email. Il est possible d’ajouter des couches de sécurité avec DKIM, SPF et DMARC, notamment pour éviter que des petits malins ne changent l’expéditeur sans se faire remarquer.

• Emails avec SPF, DKIM, DMARC, ARC et BIMI : à quoi ça sert, comment en profiter ?

Le Sender Policy Framework (SPF) « permet au serveur qui reçoit un e-mail de s’assurer que ce dernier a bien été envoyé depuis un serveur de confiance », explique OVHcloud. Si vous recevez un email provenant du domaine exemple.com, le SPF permet de vérifier que le serveur est bien autorisé à envoyer des emails au nom de exemple.com.

Avec SPF, on peut donc vérifier que l’email provient d’un serveur autorisé, mais rien de plus. N’importe qui pouvant envoyer des emails en @next.ink pourrait se faire passer pour une autre personne de @next.ink. Pour s’assurer que l’expéditeur du message est, lui aussi, autorisé, un autre protocole existe : DKIM ou DomainKeys Identified Mail.

Il permet « aux propriétaires de domaines de signer automatiquement "les courriels" provenant de leur domaine, tout comme la signature d'un chèque permet de confirmer l'identité de son auteur », explique Cloudflare. DKIM utilise un chiffrement asymétrique : une clé publique sur le serveur email et une clé privée utilisée par l’expéditeur pour signer l’en-tête de l’email.

« Les serveurs de messagerie qui reçoivent le courrier électronique peuvent vérifier que la clé privée de l'expéditeur a été utilisée en appliquant la clé publique », détaille Cloudflare. Un point important : la vérification de l’expéditeur est de la responsabilité du serveur email rattaché au nom de domaine de l’expéditeur, c’est à lui que revient la charge de s’assurer que l’utilisateur qui envoie l’email est le bon. Comme les utilisateurs doivent s’identifier, cela n’est généralement pas un problème.

Enfin, DMARC (Domain-based Message Authentication Reporting and Conformance) définit ce que doit faire un serveur de messagerie en fonction des résultats de la vérification SPF et DKIM. On parle de « politique DMARC » qui peut être de refuser en bloc les messages échouant aux tests SPF et/ou DKIM, les mettre en quarantaine ou tout simplement les accepter. Oui, un message peut louper son test SPF, échouer à DKIM et arriver tout de même dans votre boite de réception, la fleur au fusil.