Tout ce que vous devez savoir sur la sécurité SMTP

Quelles sont les menaces à la sécurité SMTP ?

Il y a un certain nombre de choses dont il faut être conscient lorsqu’on transmet ne serait-ce qu’une petite quantité d’emails. Voici ceux qui se produisent le plus souvent :

Accès non autorisé à vos emails et fuite de données

Des cybercriminels pourraient essayer d’accéder à votre serveur SMTP par lequel passe tout le courrier sortant. Pour ce faire, ils brisent vos procédures d’authentification avec des méthodes plus ou moins sophistiquées. Une fois entrés, les visiteurs indésirables peuvent accéder à vos courriers électroniques et les utiliser à leur avantage, en divulguant par exemple les données de vos utilisateurs ou en volant des informations confidentielles que vous envoyiez à vos collègues de travail.

Spam et phishing

Lorsque des fraudeurs parviennent à accéder à votre serveur SMTP, ils sont également susceptibles de l’utiliser pour envoyer des messages non autorisés à la fois à vos contacts et à des comptes externes (on parle alors d’utiliser votre serveur comme un relais ouvert). Cela permet d’envoyer du spam qui, lorsqu’il est envoyé à partir de votre domaine légitime et (probablement) bien connu, peut avoir un certain succès. Ou, pire encore, votre serveur peut être utilisé pour envoyer des courriels malveillants, demandant par exemple à vos utilisateurs de partager leurs identifiants de connexion ou leurs numéros de carte de crédit.

Malware

Les attaquants utilisent couramment les vulnérabilités du SMTP pour diffuser des logiciels malveillants aux destinataires de vos courriels mais aussi dans votre propre infrastructure. Il peut s’agir de virus, de chevaux de Troie ou de tout autre type de vers qui sont ensuite utilisés pour entraver les opérations, accéder aux serveurs, modifier les privilèges et accéder à des données sécurisées. S’ils ne sont pas combattus avec suffisamment de force, les logiciels malveillants pourraient continuer à se propager, infectant de plus en plus de serveurs et d’utilisateurs.

Attaque par déni de service

Si tout ce qui précède ne semblait pas sérieux, les cybercriminels peuvent également utiliser votre serveur SMTP pour effectuer une attaque par déni de service (DoS). Il s’agit essentiellement d’inonder d’autres serveurs avec une énorme quantité d’e-mails pour affecter leurs performances ou même provoquer un crash. Le DoS peut également être utilisé pour inonder une boîte de réception afin de masquer tout message d’avertissement concernant les failles de sécurité d’un serveur. Quel que soit le but d’une attaque DoS, ce n’est jamais bon.

Ce ne sont que quelques exemples parmi d’autres. Mais existe-t-il un moyen de sécuriser notre connexion et d’éviter un tel sort ?

Comment sécuriser le SMTP ? Qu’est-ce que SSL/TLS ?

Les fournisseurs de messagerie ont également remarqué ces vulnérabilités et, dès les premiers jours du courrier électronique, ont commencé à ajouter des couches de sécurité au protocole SMTP. SSL (Secure Sockets Layer) a été développé en 1995 par Netscape. La première version (1.0) n’a jamais été partagée avec le public en raison de ses vulnérabilités, mais la v2.0 est rapidement devenue la fonction indispensable de tout client de messagerie respectable.

Quelques années plus tard, une nouvelle norme appelée TLS (Transport Layer Security) a été publiée et a été constamment améliorée depuis. SSL a finalement été déprécié en 2015 et TLS dans sa version 1.3 (la dernière en date au moment de la rédaction de cet article) est désormais considéré comme une norme industrielle. Bien qu’il soit toujours possible d’utiliser les dernières versions de SSL, ce n’est pas recommandé en raison des diverses vulnérabilités qui ont été découvertes. Notez toutefois que les noms « SSL » et « TLS » sont utilisés de manière interchangeable et que, souvent, un fournisseur de services peut faire référence à SSL alors qu’il utilise en fait TLS.

SSL/TLS permet de chiffrer les messages échangés entre votre client de messagerie et votre serveur de messagerie. Lorsque les pirates enfreignent la sécurité du SMTP, ils ne verront qu’un ensemble de caractères apparemment aléatoires remplacer le contenu des courriels. Ils peuvent toujours utiliser leurs pouvoirs nouvellement acquis pour causer des dommages, mais au moins vous et les données de vos contacts seront protégés.

TLS prend également en charge l’utilisation de certificats numériques qui fournissent une couche supplémentaire de sécurité. Pensez à ces certificats comme des pièces d’identité ou des passeports avec lesquels chaque partie du processus s’identifie. Ce processus s’appelle un Handshake.

Comment fonctionne le Handshake ?

Nous avons déjà établi que tout courriel envoyé par SMTP voyage de la façon suivante :

1. client de messagerie de l’expéditeur
2. serveur de messagerie de l’expéditeur
3. serveur de messagerie du destinataire
4. client de messagerie du destinataire

Lorsqu’un courriel traverse l’une ou l’autre de ces étapes, une connexion est lancée et, en cas d’utilisation de TLS, les deux parties doivent établir la confiance entre elles. C’est ce qu’on appelle la poignée de main (Handshake). Le client de l’expéditeur veut savoir qu’il communique avec son propre serveur, et non avec quelque chose qui lui ressemble mais qui est en fait un piège. Le serveur veut également apprendre à mieux connaître l’autre serveur avant de lui confier un message important. Ce n’est qu’après avoir vérifié leurs papiers respectifs et établi quelques règles de coopération qu’ils procéderont à la transmission.

La poignée de main se compose de plusieurs étapes et se déroule comme suit :

1. Le client de messagerie envoie un message  »hello » dans lequel il indique les versions SSL/TLS avec lesquelles il est compatible et les types de cryptage qu’il prend en charge.
2. Le serveur répond  »hello » mais sa réponse est différente. Il inclut son certificat numérique TLS et sa clé de chiffrement publique.
3. Le client de messagerie vérifie si le certificat est légitime. Si c’est le cas, il procède à…
4. générer une clé secrète partagée avec la clé de chiffrement publique du serveur qu’il vient de recevoir il y a deux étapes.
5. Le serveur déchiffre ensuite la clé secrète partagée reçue.
6. Si tout s’est bien passé, les deux sites peuvent maintenant utiliser cette clé secrète partagée pour chiffrer et déchiffrer les messages envoyés entre eux.

Si vous êtes intéressé par une description beaucoup plus détaillée de cette rencontre, consultez cette ventilation intéressante de chaque octet utilisé dans une poignée de main TLS.

Voyez comment le chiffrement de cette interaction était, au début, asynchrone (les deux parties utilisaient des clés différentes). Au cours de la poignée de main, ils ont réussi à établir que l’utilisation de la clé secrète partagée était la voie à suivre et le chiffrement est devenu synchrone (et, par conséquent, plus rapide).

Inspectez vos e-mails

TLS opportuniste contre TLS forcé. STARTTLS expliqué.

Pour qu’une Handshake ait lieu en premier lieu, la connexion entre les deux parties doit être établie. TLS est livré avec le choix de deux approches différentes pour établir la communication :

Avec TLS opportuniste (explicite), un client de messagerie pendant un Handshake va dire à un serveur de messagerie qu’il veut parler mais en privé. En d’autres termes, il suggérera de passer d’une connexion SMTP simple, non chiffrée, à une connexion chiffrée par TLS. Si la tentative échoue, cependant, il commencera la transmission en texte brut, sans aucun cryptage appliqué.

Avec TLS forcé (implicite), un client de messagerie exigera de parler en privé (et d’utiliser la connexion cryptée) Un serveur de messagerie répondra alors si un tel arrangement lui convient ou non. S’il n’est pas compatible avec la version de TLS utilisée par le client, ne supporte pas du tout TLS ou que la connexion échoue, la transmission sera arrêtée et le courriel ne sera pas déplacé plus loin.

STARTTLS est la commande SMTP utilisée pour initier le passage à une connexion cryptée lors de l’utilisation de TLS opportuniste. Malgré son nom, elle peut également être utilisée pour initier un passage à SSL si seul ce protocole est activé pour les deux parties.

La quasi-totalité des clients de messagerie qui fournissent un chiffrement TLS à leurs utilisateurs proposent TLS opportuniste par défaut. Il est souvent possible d’activer le TLS forcé à la demande de l’utilisateur, mais veillez d’abord à considérer les avantages et les inconvénients d’une telle approche. Le choix se résume à savoir si vous voulez garantir une délivrabilité maximale (TLS opportuniste) ou une confidentialité maximale (TLS forcé). Avec la première approche, vous risquez d’envoyer quelques e-mails (probablement très peu) sans cryptage. Avec la seconde, votre délivrabilité pourrait souffrir un peu. Le choix vous appartient.

Cryptage de bout en bout

Une autre approche pour sécuriser la communication par courriel est le cryptage de bout en bout. Comme nous l’avons mentionné plus haut, SSL/TLS ne chiffrent les courriels que pendant leur trajet entre le client de messagerie de l’expéditeur et son serveur de messagerie. Un message est ensuite décrypté et il voyage jusqu’à la boîte de réception du destinataire sans aucun cryptage, étant vulnérable aux attaques.

Les méthodes de cryptage de bout en bout fournissent une approche différente. Un message est crypté sur l’appareil de l’expéditeur avant même d’être envoyé par un client. Il voyage ensuite sur le réseau (en étant souvent chiffré avec TLS en cours de route, ce qui lui confère une sécurité supplémentaire). Lorsqu’il arrive sur le client du destinataire, il est décrypté par un destinataire. Tout au long du transfert, le message est crypté à tout moment. Même s’il est victime d’un détournement, les données seront inutiles pour un voleur.

Pour que le chiffrement de bout en bout fonctionne, les deux parties doivent être compatibles avec une méthode de chiffrement donnée et disposer des bonnes clés pour chiffrer/déchiffrer un message. Disons que Charlie (un expéditeur) souhaite envoyer un message à Marie (un destinataire) en utilisant le chiffrement de bout en bout. Voici à quoi ressemblerait le processus :

1. Mary génère une clé publique et une clé privée. À partir de maintenant, elle partage la clé publique avec toute personne désireuse de lui envoyer un message mais garde sa clé privée… privée.
2. Charlie a entendu parler de la clé publique de Mary et il l’utilise pour chiffrer son message. Le contenu d’un courriel est transformé en quelque chose appelé texte chiffré, ce qui ressemble à un ensemble aléatoire de caractères.
3. Le message est envoyé du client de messagerie de Charlie jusqu’au client de Marie, en suivant les procédures standard. Si quelqu’un voyait le message en chemin, il ne verrait qu’un texte chiffré.
4. Le message arrive et Mary utilise sa clé privée pour déchiffrer le message.

Mary a réalisé que ce que Charlie avait si soigneusement chiffré était des billets d’avion pour son voyage d’anniversaire surprise. Comme c’est excitant ! Immédiatement après, elle a demandé la clé publique de Charlie, a écrit sa réponse et l’a chiffrée avec la clé reçue. Il saura quoi faire, pensa-t-elle.

Méthodes de chiffrement de bout en bout les plus populaires

S/MIME

Secure/Multipurpose Internet Mail Extensions est une méthode de chiffrement très populaire. Elle s’appuie sur un chiffrement asynchrone et, là encore, sur un ensemble d’une clé publique et d’une clé privée. Comme dans le cas de TLS, un expéditeur désireux de crypter un message utilise la clé publique d’un destinataire. Lorsqu’un message est reçu, le destinataire utilise sa propre clé privée pour voir le contenu du courriel. S/MIME vous permet également d’ajouter une signature numérique à un courriel, certifiant ainsi que vous êtes bien l’expéditeur. Cela permet d’éviter l’usurpation d’identité. Cette méthode peut être facilement ajoutée aux clients de messagerie populaires tels que Gmail ou Outlook.

PGP

Pretty Good Privacy (gotta love the name !) est probablement la méthode de cryptage la plus populaire et existe depuis le début des années 90. Elle n’est pas seulement utilisée pour chiffrer les courriels, mais aussi les fichiers, les répertoires et les partitions de disque entières. En ce qui concerne le courrier électronique, son fonctionnement n’est pas différent de celui de S/MIME. Il repose également sur la combinaison de clés privées et publiques, mais les données cryptées sont encore plus difficiles à craquer. PGP utilise un mélange de compression de données, de cryptographie à clé publique et de hachage pour obtenir une chaîne de caractères presque inviolable représentant les données protégées. Pour valider l’expéditeur, sa clé privée est également utilisée pour certifier la propriété d’un compte. Depuis 1997, PGP est disponible sous la forme d’une norme non propriétaire appelée OpenPGP et chacun est libre de l’implémenter dans son logiciel.

Bitmessage

Bitmessage est souvent appelé le « bitcoin des communications » et ses utilisateurs affirment qu’il est beaucoup plus sûr et facile à utiliser que les deux méthodes précédentes que nous avons couvertes. Pour envoyer des messages de cette manière, chaque utilisateur crée une adresse Bitmessage qui se compose de deux clés – une publique et une privée. Comme dans tous les cas précédents, une clé publique est utilisée pour chiffrer les messages et une clé privée pour les crypter. Lors du décryptage d’un message, divers processus supplémentaires sont appliqués pour certifier que vous êtes bien l’expéditeur du message. Il peut s’agir de hachage, de mappage de données, de « signature » du message ainsi que de la fourniture d’une « preuve de travail ».

Enfin, un message est envoyé à un réseau public de milliers d’utilisateurs. Chaque membre télécharge chaque message reçu mais n’est capable de déchiffrer que ceux qui sont chiffrés avec sa clé publique. Le corps du message et les métadonnées sont ainsi absolument sécurisés et pratiquement impossibles à pénétrer, tant pour les pirates occasionnels que pour les agences gouvernementales sophistiquées. Inutile de dire que Bitmessage a connu une croissance explosive après le scandale de 2013 qui a révélé les pratiques de surveillance du courrier électronique de la NSA.

Les méthodes de chiffrement de bout en bout sont certainement plus sûres que TLS et devraient être utilisées lors de l’envoi de données confidentielles. Si la mise en œuvre de Bitmessage pour envoyer des rapports hebdomadaires à votre superviseur peut être un peu exagérée, S/MIME et PGP méritent tous deux d’être pris en considération. Gardez toujours à l’esprit que les deux parties doivent être compatibles avec la méthode utilisée, sinon, l’autre partie ne comprendra pas forcément ce que vous aviez vraiment en tête.

Autres considérations

Une fois que vous avez mis en place TLS et/ou le chiffrement de bout en bout, il vaut également la peine d’examiner comment équiper vos emails de méthodes d’authentification supplémentaires. Elles sont utilisées pour empêcher l’usurpation de votre communication et aussi pour améliorer la délivrabilité de vos courriels.

Les méthodes les plus couramment utilisées sont SPF et DKIM.

SPF sert à identifier un expéditeur en téléchargeant dans les enregistrements DNS les adresses IP utilisées pour envoyer des courriels au nom d’un domaine donné. Le client récepteur, avant de délivrer un message, vérifie si la bonne adresse a été utilisée et pourrait écarter un message s’il détecte des anomalies.

DKIM, quant à lui, est un certificat numérique envoyé avec un courriel. Il permet au destinataire d’un message de vérifier si le contenu d’un courriel ou les en-têtes n’ont pas été modifiés (falsifiés) lors d’une transmission. Un test DKIM raté affecte la délivrabilité d’un message et pourrait être une raison pour qu’il échappe à une boîte de réception.

DMARC est la plus sophistiquée des trois méthodes et elle s’appuie sur les deux autres méthodes pour effectuer des vérifications supplémentaires. C’est la seule méthode qui, à l’exception de l’exécution d’un test, peut également suggérer à un serveur de réception ce qu’il faut faire si un message échoue à un contrôle.

Il vaut la peine d’avoir ces trois méthodes configurées pour votre domaine. Nous les couvrons tous en détail dans des articles séparés, consultez-les aux liens ci-dessus.

Enfin, il vaut la peine de vérifier si votre serveur SMTP fonctionne comme prévu. Vous pouvez le faire via Telnet ou utiliser un certain nombre d’outils qui proposent de telles vérifications. Consultez notre article sur le test du serveur SMTP.

Si vous cherchez un moyen de tester les e-mails en toute sécurité, vous n’avez pas réellement besoin de les envoyer à de vrais utilisateurs. Mailtrap crée un faux serveur SMTP qui capture tous vos emails de test sans risque de spammer les vrais utilisateurs. Vous pouvez ensuite prévisualiser vos messages et les transférer vers de vraies boîtes de réception avant de les mettre en œuvre sur une production.

Essayer Mailtrap gratuitement

Résumé

Nous avons commencé par dire à quel point la connexion SMTP est vulnérable. Heureusement, il existe de nombreuses méthodes qui peuvent la rendre vraiment sûre et beaucoup ont déjà été mises en œuvre dans divers clients de messagerie. Nous espérons que vous avez apprécié la lecture de cet article, consultez les autres articles de notre blog où nous parlons beaucoup des tests et de l’envoi d’emails. Jusqu’à la prochaine fois !