S/MIME est une méthode bien établie pour envoyer des e-mails cryptés et signés, basée sur des normes publiques Internet. Nous rencontrons régulièrement des demandes pour S/MIME, particulièrement de la part d'industries réglementées telles que la banque, la santé et la finance.
S/MIME est une méthode établie de longue date pour envoyer des e-mails chiffrés et signés, basée sur des normes Internet publiques. Nous rencontrons régulièrement des exigences pour S/MIME, en particulier de la part de secteurs réglementés tels que la banque, la santé et la finance. S/MIME est souvent requis lors de communications entre entreprises et agences gouvernementales, par exemple.
Une autre norme de courrier sécurisé, PGP (amusamment nommée « Pretty Good Privacy »), est utilisée davantage pour les communications sécurisées de personne à personne. Elle est moins populaire maintenant parce que les versions grand public des clients de messagerie basés sur le Web, tels que Gmail et Outlook/Hotmail, ne peuvent pas afficher les e-mails chiffrés. C’est l’une des raisons pour lesquelles de nombreuses communications de personne à personne nécessitant de la confidentialité ont migré vers des plateformes telles que WhatsApp (et bien d'autres) qui offrent un chiffrement de bout en bout natif.
Tant PGP que S/MIME nécessitent un client de messagerie capable d'utiliser des clés et des certificats. De nombreux clients de bureau et mobiles, y compris Apple Mail, Microsoft Outlook et Mozilla Thunderbird répondent aux critères, tout comme les versions professionnelles de certains clients Web tels que Microsoft Office 365. La configuration des clés demande du travail, mais de nombreuses organisations considèrent toujours cela comme valable, malgré les récentes divulgations de vulnérabilités nécessitant des remèdes pour bloquer le chargement de contenu distant.
S/MIME existe depuis 1995 et a connu plusieurs révisions; la version actuelle est couverte par RFC 5751. Il requiert un échange de clés publiques, une tâche non triviale qui nécessite souvent le soutien d'une équipe informatique ou d'une ressource similaire. Pour les organisations utilisant une infrastructure de messagerie sur site, la mise en œuvre de S/MIME nécessite des considérations supplémentaires pour des plateformes comme PowerMTA et Momentum, que nous abordons dans notre guide sur S/MIME pour la messagerie sécurisée sur site. Cependant, il existe des approches automatisées pour rationaliser ce processus, telles que la collecte des clés publiques des destinataires via des systèmes basés sur les e-mails qui peuvent simplifier la gestion des clés pour les flux de courriels générés par des applications. C’est là que des solutions commerciales d'entreprises partenaires de SparkPost, telles que Virtru et Echoworkx, interviennent, facilitant la sécurité pour les courriers professionnels de personne à personne (voir notre guide pratique SparkPost/Echoworkx pour plus d'informations).
Ceci étant dit, explorons plus en profondeur le bon vieux S/MIME et voyons ce que nous pouvons en faire.
Pourquoi devrais-je m'en soucier ?
La version courte :
Le chiffrement vous offre la confidentialité des messages.
La signature vous donne l'authentification (de l'expéditeur), la non-répudiation de l'origine et des vérifications d'intégrité des messages.
S/MIME fonctionne différemment de DKIM et DMARC et peut coexister avec eux.
Confidentialité
Si vos messages ne contiennent rien de personnel, privé ou d'importance légale, alors vous n'aurez probablement pas besoin de penser à S/MIME. Les systèmes modernes de livraison d'e-mails tels que SparkPost utilisent déjà le "TLS opportuniste" pour sécuriser le transport du message du serveur d'envoi au serveur récepteur.
La partie "opportuniste" signifie cependant que si le serveur d'envoi ne peut pas négocier une connexion sécurisée, nous enverrons le courrier en clair. Cela ne convient pas si vous voulez obliger le message à être sécurisé de bout en bout. Vous pouvez jeter un œil à quels fournisseurs de boîtes aux lettres prétendent offrir un support TLS et lesquels le font réellement. En supposant que le serveur du destinataire supporte TLS, votre message est sécurisé comme suit :
Le TLS sécurise les conversations entre serveurs de messagerie (c'est pourquoi on l'appelle Transport Layer Security). Le MIME (y compris S/MIME) concerne le contenu du message et son traitement, et peut être considéré comme faisant partie de la "couche de présentation".
S/MIME sécurise le contenu du message de bout en bout, de l'origine du message au client de messagerie du destinataire, en encapsulant le corps du message.
S/MIME crypte le corps du message avec la clé publique du destinataire. Le corps ne peut être décodé sans la clé privée du destinataire—pas même par une "personne au milieu" telle que votre FAI, SparkPost ou le serveur mail du destinataire.
La clé privée n'est jamais divulguée ; elle est gardée en possession exclusive du destinataire. Le message chiffré voyage sur Internet jusqu'au serveur de réception des mails. Lorsqu'il arrive dans la boîte de réception du destinataire, il est (habituellement automatiquement) déchiffré avec leur clé privée et devient lisible.
Quelques pièges de S/MIME à connaître :
Le chiffrement S/MIME a l'effet secondaire d'empêcher l'analyse de messages entrants à la recherche de logiciels malveillants par le serveur car la charge utile du message est en forme chiffrée et donc non identifiable.
Notez que les en-têtes de message (De :, À :, Objet :, etc.) ne sont pas chiffrés, de sorte que le contenu de la ligne d'objet doit être créé en tenant compte de cela.
Signature – authentification
S/MIME fournit également au destinataire la possibilité de vérifier que l'identité de l'expéditeur du message est bien celle qu'elle prétend être.
L'email de l'expéditeur a un certificat joint, qui, un peu comme le certificat sur un site web sécurisé, peut être tracé jusqu'à une autorité de délivrance. Pour une description complète du processus de signature, voir le PDF du processus de signature S/MIME.
Nous prendrons l'approche de d'abord signer le courrier, puis de le chiffrer, donc le processus ressemble à ceci.
Non-répudiation
Un autre avantage utile de la signature pour le destinataire est la non-répudiation de l'origine. Considérez une situation où un message électronique est utilisé pour approuver un contrat. Le destinataire reçoit le contrat dans un message de l'expéditeur. Si l'expéditeur tente plus tard de dire, "Non, je ne vous ai jamais envoyé ce message", alors le message reçu montre que le certificat de l'expéditeur a en fait été utilisé.
Intégrité du message
Le processus de signature crée une empreinte numérique du message source en clair (connu sous le nom de résumé du message), chiffre le résumé en utilisant la clé privée de l'expéditeur et l'inclut dans le message livré. Le client de messagerie du destinataire peut dire si le corps du message a été altéré.
Peut-être vous dites-vous, "Je pensais que DKIM me fournissait des vérifications d'intégrité des messages!" Eh bien oui, DKIM fournit des vérifications d'intégrité du corps du message et de l'en-tête du message - des garanties anti-altération. Cependant, un échec (ou une absence) de DKIM ne provoquera généralement pas que le message entrant soit marqué comme complètement invalide … sauf si une politique DMARC de p=reject est en jeu (voir notre article de blog DMARC : Comment protéger votre réputation d'email). DKIM est un des nombreux facteurs utilisés par le FAI pour l'attribution fiable de la réputation à un domaine et est, bien sûr, une partie essentielle de votre pile de messagerie.
Votre client de messagerie vous le montrera de manière proéminente si un message S/MIME échoue aux vérifications de signature :
Résumé : de bout en bout (S/MIME) vs de serveur à serveur (DKIM, DMARC, TLS)
S/MIME est une capacité de couche de présentation qui peut fonctionner entre deux utilisateurs finaux d'email (avec certificats/clés valides) sans aucune action de l'administrateur d'email. S/MIME fournit le chiffrement et la signature et est personnel à chaque utilisateur.
S/MIME est lié à l'adresse d'envoi complète (partie locale et partie domaine), donc, par exemple, alice@bigcorp.com et bob@bigcorp.com devraient avoir des certificats différents. En revanche, DKIM valide que l'e-mail provient du domaine de signature. DKIM est un sujet entier en lui-même ; cet article est un bon point de départ.
La configuration DKIM et DMARC est effectuée par votre administrateur de messagerie (travaillant sur le serveur de messagerie et les enregistrements DNS). Une fois configurés, ils sont actifs pour les domaines, plutôt que pour les utilisateurs individuels.
Comment cela se rapporte-t-il à SparkPost ?
Quels clients prennent en charge S/MIME ?
Consumer Gmail
Le client web Gmail ordinaire affiche les signatures de courriels entrants (voir ci-dessous), mais il n'est pas configuré pour conserver votre clé privée pour lire les messages chiffrés. Même si cela était possible via des plugins tiers, télécharger votre clé privée n'est pas une bonne idée d'un point de vue sécurité.
Je n'ai pas pu amener Yahoo! Mail à décoder les signatures dans les messages du tout.
La version grand public des comptes Microsoft Outlook/Hotmail vous alerte de la présence d'une signature S/MIME, mais ne vous donne pas un accès complet pour voir ou vérifier le certificat.
Mail professionnel hébergé
Pour les organisations avec mail hébergé, Microsoft Office 365 et G Suite Enterprise prennent en charge S/MIME.
Clients de messagerie Outlook
Microsoft Outlook basé sur le client (par exemple 2010 pour Windows) fonctionne :
Cliquer sur les icônes vous donne plus d'informations :
Sur Outlook 2010 / Windows, le magasin de certificats est accessible via Fichier / Options / Centre de gestion de la confidentialité / Paramètres du Centre de gestion de la confidentialité / Sécurité des courriels / Importer / Exporter.
Thunderbird – multiplateforme et gratuit
Si vous cherchez un client gratuit, Mozilla Thunderbird fait l'affaire. Il est disponible sur PC, Mac, et Linux, et prend en charge S/MIME sur toutes ces plateformes. Voici à quoi ressemble un message sur Mac. L'icône « enveloppe scellée » indique que le message est signé, et le cadenas indique qu'il a été chiffré.
Cliquer sur l'enveloppe/cadenas affiche des infos sur le message :
Thunderbird a son propre magasin de clés, accessible de manière similaire sur chaque plateforme :
Mac via Préférences / Avancé / Certificats / Gérer les certificats
PC : menu (« hamburger » en haut à droite), Avancé / Certificats / Gérer les certificats
Linux : menu (« hamburger » en haut à droite), Préférences / Avancé / Gérer les certificats
Mail Mac
Mail Mac prend également en charge S/MIME. Il utilise votre trousseau de clés Mac pour conserver vos clés.
Mail iOS
Tout d'abord, importez le certificat de votre compte de messagerie comme ceci, puis vous pouvez voir les courriels signés et chiffrés S/MIME. Ils ne semblent pas vraiment différents à l'écran de visualisation.
Android
Certains appareils et applications prennent en charge S/MIME ; il y a beaucoup de variété disponible. Samsung propose un guide.
Enfin…
Voici notre aperçu rapide des utilisations pratiques de S/MIME. Si vous souhaitez obtenir vos propres certificats de messagerie, il y a une liste de fournisseurs ici. J'ai trouvé que Comodo fonctionne bien (gratuit pour un usage non commercial - ouvrez-le dans Firefox, pas Chrome).
Dans la partie 2, nous explorerons comment appliquer la signature et le cryptage S/MIME aux messages que vous envoyez via SparkPost.
Lecture supplémentaire
Microsoft a un bon article d'introduction sur S/MIME dans leur documentation.
Pour plus d'informations sur la vulnérabilité EFAIL et comment elle a été traitée, voir le site officiel EFAIL. D'autres explications faciles à suivre sont disponibles sur la page wiki EFAIL et dans l'article de blog de CipherMail EFAIL : Quelle est la vulnérabilité, PGP, S/MIME ou votre client mail ?.
