SecurityInsider
Le blog des experts sécurité Wavestone

SMTP STS : un effort pour mieux sécuriser les emails


L’échange d’emails fonctionne grâce au fameux protocole historique SMTP (Simple Mail Transfer Protocol). Inventé dans les années 80, celui-ci fait transiter toutes les informations (données et métadonnées) en clair et ce, tout au long de la chaîne de transmission (du poste client émetteur au poste client récepteur en passant par tous les serveurs de messagerie intermédiaires). L’atteinte à la confidentialité et l’intégrité des données est alors possible.
Afin de pallier à ce problème le standard SMTPS (SMTP encapsulé dans un tunnel SSL/TLS) a été inventé en 2002 afin de sécuriser l’échange SMTP. Ce dernier est malheureusement vulnérable aux attaques de type Man in The Middle permettant notamment à un attaquant d’écouter le trafic de manière illégitime.
C’est alors que SMTP STS entre en jeu. Ce nouveau protocole, toujours en cours d’élaboration, devrait enfin permettre de couvrir les risques exposés par SMTP et SMTPS.
Le protocole SMTP, c’est simple et fort !
Le protocole SMTP a été créé pour envoyer des emails, c’est-à-dire transférer des emails vers des serveurs de messagerie. Il se situe au niveau applicatif (couche 7 du modèle OSI), reposant sur TCP (couche 4) pour le transport et utilisant par défaut le port 25.
Voici un exemple d’interaction avec un serveur SMTP (en orange) via telnet. On note son fonctionnement très simple, dépourvu d’authentification et de chiffrement.
telnet smtp.xxxx.xxxx 25
Connected to smtp.xxxx.xxxx.
220 smtp.xxxx.xxxx SMTP Ready
HELO client
250-smtp.xxxx.xxxx
250-PIPELINING
250 8BITMIME      
MAIL FROM: <auteur@yyyy.yyyy>
250 Sender ok
250 Recipient ok.
DATA
354 Enter mail, end with "." on a line by itself
Subject: Test

Corps du texte
.
250 Ok
QUIT
221 Closing connection
Connection closed by foreign host.
Note : le protocole SMTP ne permet pas de rapatrier les emails du serveur de messagerie vers le logiciel client ; les standards POP et IMAP ont été créés dans ce but.
SMTPS, du mieux mais toujours vulnérable
Le standard SMTPS (SMTP avec STARTTLS) a notamment pour objectif d’apporter les améliorations suivantes :
  l’authentification point à point, c’est-à-dire entre le client et les serveurs et entre les serveurs eux-mêmes ;
  l’intégrité des données;
  la confidentialité des échanges.
SMTPS repose sur TCP (sur le port 587) avec l’extension TLS (niveau session, couche 5 du modèle OSI).
En SMTPS, lors de l’initialisation de la connexion, le client demande au serveur s’il supporte TLS. Cela rend le standard vulnérable à des attaques de type « downgrade attack » visant à forcer la non utilisation de TLS, on revient donc sur du simple STMP. Les données étant non chiffrées, leur interception en transit est possible.
Description du mécanisme de « handshake » SMTPS [1] :
D’un point de vue fonctionnel, SMTPS préfère laisser passer un email en clair si un des serveurs ne supporte pas TLS plutôt que de ne pas le transférer. Un choix fait pour simplifier l’adoption de STARTLS et éviter que le déploiement de ce protocole ne vienne bloquer certains internautes dont le fournisseur de messagerie n’aurait pas adopté les nouveaux protocoles de sécurité.
Une autre vulnérabilité de STARTTLS réside dans la vérification du certificat présenté par le serveur : seul prérequis imposé, le certificat présenté doit correspondre à l’enregistrement MX associé au serveur de messagerie. Or, excepté DNSSEC [2] encore très peu déployé aujourd’hui, il n’y a pas de moyen de signer et de vérifier que l’enregistrement MX et le serveur associé appartiennent bien au même domaine. Un attaquant peut donc fournir au serveur expéditeur un faux enregistrement DNS, lui permettant de se positionner en MiTM.
Partant de ces constats, certains des plus grands acteurs du Web (dont Google, Microsoft, Yahoo!, Comcast, LinkedIn, and 1&1 Mail & Media Development) travaillent ensemble afin de mieux sécuriser l’échange d’emails. Ce travail a notamment abouti à l’ébauche du standard SMTPS STS, corrigeant les deux vulnérabilités expliquées précédemment.
SMTP STS, késako ?
Le standard SMTP STS [3] (SMTP Strict Transport Security), fruit du travail d’acteurs majeurs du Web est actuellement en cours d’étude. Il vise à forcer les serveurs de messagerie à déclarer publiquement sur le réseau leur capacité à accepter des connexions sécurisées via TLS ainsi que leurs méthodes de validation des certificats.
En pratique le client vérifie si le serveur supporte TLS et s’il présente un certificat valide (concordance des noms, certificat non-expiré et non révoqué, etc.). Si une de ces conditions n’est pas remplie, l’email n’est pas envoyé et l’utilisateur en est informé. En ce sens, SMTP STS est comparable au protocole HSTS (HTTP Strict Transport Security), destiné à assurer la confidentialité des échanges HTTP.
SMTP STS repose sur quatre composants principaux :
  • La politique sémantique : elle précise la manière dont le support de TLS par le serveur cible doit être vérifié et son certificat validé ;
  • La politique d’authentification : il décrit comment l’authenticité de la politique fournie doit être déterminée (via PKI Web ou DNSSEC) :
  • Le rapport d’échec : il formalise le reporting des erreurs ; exemples de types d’erreurs :
    • Inconsistance entre les enregistrements MX et/ou les noms de domaine et d’hôte ;
    • Certificat invalide (chemin de certification invalide, CA invalide, etc.) ou expiré ;
    • STARTTLS non supporté ;
    • Incapacité à valider les enregistrements DNSSEC.
  • La gestion des échecs : elle détaille la manière dont le serveur expéditeur peut gérer les erreurs.
L’ébauche de ce futur potentiel standard a été soumise à l’IETF (Internet Engineering Task Force) le 18 mars 2016 afin que son contenu soit étudié et approuvé.
Le cas échéant, il pourrait ensuite être mis en œuvre par les différents fournisseurs de services de messagerie.
Conclusion
Le standard STMP STS permettra d’offrir une couche de sécurité plus robuste pour l’échange des emails. Il devrait notamment permettre de se prémunir des attaques de type Man in The Middle actuellement possibles, cela en forçant l’authentification des serveurs de messagerie et l’utilisation de mécanismes de chiffrement.
En d’autres termes, il participe à sécuriser le canal de communication. Il ne restera donc pas moins nécessaire de chiffrer le contenu des emails [4] afin d’en garantir la confidentialité de bout en bout.
Il semble en effet délicat de faire confiance à l’ensemble des grands acteurs du Web et des télécommunications, administrateurs des serveurs de messagerie. Par ailleurs cette recommandation revient simplement à appliquer le principe de défense en profondeur.
Sources :
[4] Chiffrer les pièce-jointes via des logiciels (ex. Zed!, AxCrypt, Encryption Wizard) et/ou les emails (via S/MIME ou PGP par ex.)

Mathieu HARTHEISER

Aucun commentaire:

Enregistrer un commentaire