Nous entretenons un curieux rapport avec l’e-mail. C’est un peu « je t’aime, moi non plus », non ?
Un employé de bureau en reçoit environ 121 chaque jour. Pas étonnant que chacun en entreprise élabore toutes sortes de mécanismes pour trier ses courriels, retenir ceux qui méritent leur attention et ignorer les autres. Il y a quelques années, le même traitement avait été réservé à ce bon vieux courrier « physique ». Combien de publicités fallait-il trier avant d’identifier les enveloppes les plus importantes ?
Point intéressant : qu’il s’agisse d’un courrier numérique ou physique, la décision de l’ouvrir ou de le jeter repose sur un seul facteur : le nom de l’expéditeur inscrit sur l’enveloppe.
Certificats S/MIME : pourquoi bénéficient-ils d’une telle confiance ?
Authentification de l’expéditeur d’un e-mail
Mais est-ce vraiment un critère de tri suffisant ? Comment être sûr que le nom sur l’enveloppe n’a pas été falsifié ?
Pour être honnête, si l’on n’y prête pas plus d’attention que cela, il est impossible de le savoir ! Pour le courrier papier, il y a certes des garanties avec les signatures, les timbres, les cachets et les procédures que suivent les personnes chargées de traiter notre courrier. Quand bien même, cela n’empêche pas la circulation de faux documents officiels, très crédibles ; les criminels mettent les moyens pour tromper leurs victimes et leur prendre leur argent.
Et personne n’est à l’abri, même les meilleurs ! Il y a quelques années, je reçois une facture de mon transporteur que je lui règle. Or, quelques semaines plus tard, je reçois la même. En observant de plus près les deux factures, je remarque que le numéro du compte qui figure sur la seconde est différent. Un coup de fil au transporteur me permet alors de comprendre qu’il s’agit d’une arnaque, plutôt astucieuse puisqu’il était impossible de distinguer le courrier frauduleux du vrai !
Pour le courrier électronique, d’autres mécanismes permettent de déterminer si un message est légitime ou non. Je ne saurais que trop vous recommander ces outils, dans la mesure où falsifier le nom explicite de l’adresse de l’expéditeur (nom et adresse électronique affichés au destinataire) ne requiert pas de compétences techniques poussées. En langage technique, on parle d’usurpation ou spoofing en anglais. Mais plutôt qu’un long discours, voyez plutôt à quel point il est facile de créer une fausse adresse e-mail :
De quels mécanismes dispose-t-on pour prévenir et détecter les courriels frauduleux ?
DKIM, SPF et DMARC
Les mécanismes DomainKey Identified Mail (DKIM), Sender Policy Framework (SPF) et Domain-based Message Authentication, Reporting & Conformance (DMARC) sont basés sur le DNS et conçus pour prévenir l’usurpation de domaines de messagerie.
Voyons chacun en détail et étudions leur fonctionnement, leur champ d’action et leurs limites.
SPF
L’idée derrière le SPF est simple. Quand on configure le SPF pour un domaine, un enregistrement TXT DNS spécifique à ce domaine est créé. Un serveur de messagerie correctement configuré côté destinataire, qui traite un courrier envoyé depuis le domaine de l’expéditeur, tombera sur l’enregistrement SPF lors de la résolution DNS.
Pour mieux comprendre, observons la première partie de l’enregistrement SPF de globalsign.com :
v=spf1 ip4:114.179.250.0/30 ip4:211.123.204.251/32 ip4:27.121.42.215/32 […] -all
La logique ici est assez simple. v=spf1 déclare que cette entrée concerne le SPF. La plage d’adresses IP indique toutes les adresses IP que le serveur de messagerie du destinataire doit accepter comme étant le point d’origine d’un e-mail qui contient le domaine globalsign.com. Et — all signifie que si une autre adresse IP envoie un courriel pour le compte de globalsign.com, le serveur de messagerie du destinataire doit mettre ce message en quarantaine ou le rejeter complètement.
L’entrée complète serait un peu plus longue et comprendrait une liste de domaines autorisés à envoyer des messages pour le compte de globalsign.com, mais ce que nous avons indiqué plus haut constitue l’essentiel. Le SPF présente cependant certaines limites. Face aux e-mails transférés et aux techniques d’usurpation avancées qui trafiquent également l’adresse IP de l’expéditeur, le SPF peut se révéler inefficace. Dans ce cas, d’autres mécanismes sont nécessaires pour créer des niveaux de sécurité supérieurs.
DKIM
Le DKIM a été créé pour cela. Ce mécanisme offre un niveau de garantie d’authenticité supérieur pour la partie « domaine » de l’e-mail d’un expéditeur. La raison ? L’utilisation d’une signature cryptographique (similaire au S/MIME, mais pas tout à fait équivalente… nous y reviendrons). Pour configurer DKIM, il faut – entre autres conditions – créer une paire de clés publique/privée. La clé publique est ensuite notée dans la zone DNS du domaine et peut être récupérée par le serveur de messagerie du destinataire pour valider les courriels envoyés depuis ce domaine — ces e-mails étant signés avec la clé privée correspondante.
Examinons à nouveau l’une des entrées pour globalsign.com:
"v=DKIM1;k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1vhugV30ayqwRy2mu+m6QyxvdVtHee/Chr
UqtrPflazjf3LfuGryocUGTZ66DsHZeTpjqdcRRXms1+xpVsqqeiXipw4jNPwx9VpyIyg0suI/2QYsIjKyj0
OFYWe22Ilgp/zjXXJUxJ4fTqT5ae0cAX5u3GNsj6dA8u9n3atIlIwIDAQAB"
Le principe est le même que pour le SPF. v=DKIM1 déclare que cette entrée est destinée à DKIM. k=rsa indique au serveur de messagerie du destinataire que cette paire de clés est de type RSA et p=[…] désigne la clé publique elle-même. Encore une fois, c’est assez simple. Désormais, lorsqu’un courriel provenant de globalsign.com est envoyé, le serveur de messagerie de globalsign.com utilise la clé privée DKIM pour signer le courriel de manière cryptographique. À cet effet, l’e-mail est « haché », ce hash (ou condensat) est chiffré à l’aide de la clé privée et attaché au courriel. Le serveur de messagerie du destinataire peut alors hacher à nouveau le courriel et déchiffrer le hachage chiffré à l’aide de la clé publique qu’il a récupérée dans l’entrée DNS. Si les deux hachages concordent, on a l’assurance que le courriel provient bien de globalsign.com et n’a pas été altéré.
DMARC
DMARC complète SPF et DKIM en ajoutant des règles supplémentaires pour indiquer au serveur de messagerie du destinataire la conduite à tenir avec les courriels qui ne respectent aucune des politiques susmentionnées.
Analysons une nouvelle fois l’entrée pour globalsign.com:
v=DMARC1; p=reject; rua=mailto:dmarc@globalsign.com
Comme pour SPF et DKIM, v=DMARC1 indique simplement que cette entrée DNS TXT déclare des politiques DMARC. P=rejet correspond à la politique à appliquer aux courriels qui ne répondent pas aux critères ci-dessus. Dans le cas présent, « reject » signifie que le serveur de messagerie du destinataire doit toujours rejeter ces e-mails. Si l’on avait l’indication « quarantine », les e-mails devraient être déplacés vers un lieu de quarantaine — à savoir un dossier Indésirables ou Spams. Quant à l’indication « none », elle laisserait au serveur de messagerie du destinataire le soin de juger par lui-même si les courriels doivent être rejetés, mis en quarantaine ou autorisés.
rua=mailto:dmarc@globalsign.com indique ensuite une ou plusieurs adresses électroniques à notifier en cas d’échec de la validation SPF ou DKIM. Cela peut être utile pour calmer les ardeurs des cybercriminels qui tenteraient d’usurper un domaine, certains domaines étant souvent visés par des tentatives d’usurpation.
Et pour combler les manques : le S/MIME
Si SPF, DKIM et DMARC améliorent considérablement la sécurité du courrier électronique, ils n’offrent pas de solution complète. On note au moins trois points faibles :
- Toutes ces politiques sont basées sur le DNS et peuvent donc être contournées. Il suffit pour cela d’usurper la résolution DNS côté destinataire ou, simplement, de remplacer l’adresse de l’expéditeur par une adresse homographe ou une alternative ne partageant pas les politiques du domaine authentique.
- L’authenticité de l’e-mail est limitée à la partie domaine du courriel. Autrement dit, même si l’on peut avoir l’assurance que l’e-mail provient bien d’un domaine en particulier, la partie ne correspondant pas au domaine peut toujours être usurpée. L’expéditeur peut se retrouver à la merci de personnes (en interne) mal intentionnées qui usurperaient des e-mails pour le compte d’un autre service interne ou de quelqu’un d’autre.
- Les signatures DKIM n’étant appliquées que par le serveur de messagerie de l’expéditeur, et validées par le serveur de messagerie du destinataire, l’intégrité du contenu et l’authenticité de l’expéditeur ne sont pas garanties à 100 % de bout en bout. Le message reste vulnérable entre le client et le serveur de messagerie, tant pour l’expéditeur que pour le destinataire. Des [certificats] TLS correctement mis en œuvre pour les serveurs de messagerie de l’expéditeur et du destinataire permettent d’atténuer le problème — mais c’est un autre sujet qui dépasse le cadre de cet article.
Illustration 1 : Schéma simplifié de l’acheminement d’un e-mail standard, avec les résolutions DNS correspondantes
C’est là que le S/MIME présente des avantages supérieurs aux SPF, DKIM et DMARC :
- Les signatures S/MIME sont appliquées directement par le client de messagerie et sont uniquement validées par le client de messagerie du destinataire. Le message ne peut être manipulé ou modifié, même entre le serveur de messagerie et le client de messagerie.
- La clé publique pour la validation de la signature est jointe au certificat qui accompagne le courriel. Le client de messagerie n’a donc pas besoin d’une entrée DNS.
- L’organisation de l’expéditeur indiquée sur le certificat a également été vérifiée par l’autorité de certification émettrice du certificat S/MIME. Une personne malintentionnée qui utiliserait une adresse électronique homoglyphe ne pourrait donc pas utiliser le nom de l’organisation du domaine d’origine.
- Enfin, le nom basé sur la RFC 822 figurant dans le certificat doit correspondre exactement au nom explicite (ou nom d’affichage) associé à l’adresse e-mail. L’authenticité de l’expéditeur est désormais garantie au niveau de l’adresse électronique et plus seulement au niveau du domaine. Cela réduit considérablement les points faibles listés plus haut.
Du bon, du mieux et du top du top… qu’allez-vous choisir pour garantir la sécurité de votre messagerie d’entreprise ?
Sécurité des e-mails : 5 bonnes raisons d'utiliser les certificats S/MIME
Toutes les organisations doivent-elles privilégier le S/MIME par rapport au SPF, DKIM et DMARC ? Pas du tout.
Toutes les organisations doivent-elles privilégier le S/MIME par rapport au SPF, DKIM et DMARC ? Pas du tout.
Les organisations doivent avoir correctement configuré leurs SPF, DKIM et DMARC — c’est le strict minimum. Or, comme souligné précédemment, elles ne vont pas toutes au bout de la démarche. Celles qui souhaitent fournir le plus haut niveau de sécurité aux destinataires de leurs e-mails doivent privilégier les certificats S/MIME. N’oubliez pas : le S/MIME permet de chiffrer de bout en bout les e-mails, ce qui n’est pas du tout le cas avec SPF, DKIM et DMARC.
Le courrier électronique a opéré un retour en force ces deux dernières années, profitant sans doute de l’essor du commerce en ligne et du passage au télétravail lors de la pandémie. En fait, plus de 306 milliards d’e-mails transitent chaque jour (Statista, 2021, via Hubspot).
La tendance n’a pas échappé aux hackers qui cherchent de nouveaux moyens sophistiqués d’infiltrer les données des entreprises et de semer le chaos. Les entreprises prévoyantes mettront en place les méthodes de sécurisation de messagerie les plus fiables qui existent. Et aujourd’hui, cela passe par le S/MIME.
Heureusement, au fil du temps les méthodes de déploiement et de gestion des certificats S/MIME se sont améliorées et ont gagné en transparence. Découvrez comment le portail AEG (Auto Enrollment Gateway) simplifie l’inscription et la révocation des certificats S/MIME. Vous pouvez aussi jeter un œil à notre gamme complète d’outils de sécurité pour messagerie d’entreprise.
