S/MIME : Qu'est-ce que c'est, pourquoi cela m'intéresse-t-il et comment cela se rapporte-t-il à SparkPost ?
Oiseau
19 déc. 2018
1 min read
Points Clés
Premise : S/MIME (Secure/Multipurpose Internet Mail Extensions) est une norme de longue date pour l'envoi de courriels signés et chiffrés—critique pour les industries qui traitent des données sensibles comme la finance, la santé et le gouvernement.
Objectif : Expliquer ce que fait S/MIME, pourquoi cela importe, comment il diffère de DKIM/DMARC/TLS, et comment il s'intègre avec SparkPost.
Points forts :
Définition : S/MIME permet deux fonctionnalités principales :
Chiffrement → Protège le contenu des messages (confidentialité).
Signature → Confirme l'identité de l'expéditeur, empêche la falsification et assure la non-répudiation.
Utilisation dans l'industrie : Requis ou préféré par les secteurs réglementés nécessitant la confidentialité des messages de bout en bout et une identité vérifiable.
Comparaison avec d'autres protections de messagerie :
TLS : Sécurise la transmission entre les serveurs (couche de transport).
S/MIME : Sécurise le contenu même du message (couche de présentation).
DKIM/DMARC : Authentifient les domaines, pas les individus, et fonctionnent au niveau administrateur/serveur.
Mécanique :
Utilise des paires de clés publiques/privées et des certificats numériques délivrés pour chaque identité email (par exemple, alice@company.com).
Nécessite des clients de messagerie pris en charge (Apple Mail, Outlook, Thunderbird, iOS Mail, etc.).
Limites :
Les clés et certificats peuvent être complexes à gérer.
Les charges utiles chiffrées ne peuvent pas être analysées pour détecter les logiciels malveillants.
Les en-têtes (De, À, Sujet) restent visibles.
Intégration avec SparkPost :
Les utilisateurs de SparkPost peuvent signer des messages avec S/MIME pour une authenticité accrue.
Pour l'envoi chiffré, les destinataires doivent d'abord partager leur clé publique (par exemple, en envoyant un message signé).
Les partenaires commerciaux comme Virtru et Echoworx simplifient cela pour les flux de travail d'entreprise.
Prochaines étapes :
Partie 2 de la série démontre comment signer et chiffrer des messages via SparkPost.
Les parties ultérieures montrent les configurations sur site utilisant PowerMTA et Momentum.
Points forts des Q&A
Pourquoi S/MIME est-il important si j'utilise déjà TLS ou DKIM ?
TLS protège la connexion entre les serveurs, tandis que S/MIME protège le contenu lui-même—assurant qu'il reste privé et vérifiable même après la livraison.
Qui a le plus besoin de S/MIME ?
Industries réglementées (finance, gouvernement, santé) et toute organisation qui envoie des e-mails confidentiels, juridiquement contraignants ou sensibles à l'identité.
Quels problèmes S/MIME résout-il ?
Il empêche l'interception et l'usurpation, garantit l'authenticité de l'expéditeur, et fournit la preuve qu'un message n'a pas été altéré.
SparkPost prend-il en charge nativement S/MIME ?
SparkPost prend en charge l'envoi de messages au format S/MIME ; vous devez simplement signer/chiffrer votre contenu avant de le soumettre via API ou SMTP.
Comment puis-je obtenir des certificats ?
Les certificats peuvent être émis par des fournisseurs tels que Comodo (gratuit pour un usage non commercial) ou auto-signés pour des tests internes.
Que faire si mon destinataire ne peut pas lire les e-mails chiffrés ?
Ils verront toujours l'en-tête du message signé, mais pour le déchiffrer, ils doivent installer un client compatible et avoir leur clé privée importée.
Comment l'échange de clés est-il géré pour les emails générés par l'application ?
Les destinataires peuvent envoyer un email à votre service avec un message signé ; leur clé publique peut ensuite être extraite automatiquement via des webhooks de relais entrant.
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.
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.
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 me soucier ?
La version courte :
Le chiffrement vous offre la confidentialité de vos messages.
La signature vous offre l'authentification (de l'expéditeur), la non-répudiation de l'origine et les vérifications de l'intégrité du message.
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 juridiquement important, 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 destinataire.
La partie « opportuniste » signifie toutefois que si le serveur d'envoi ne peut pas négocier une connexion sécurisée, nous enverrons le courrier en texte clair. Ce n'est pas convenable si vous souhaitez forcer le message à être sécurisé de bout en bout. Vous pouvez jeter un œil à les fournisseurs de messagerie qui revendiquent le support TLS et ceux qui le font réellement. Supposons que le serveur du destinataire supporte TLS, votre message est sécurisé de cette manière :
TLS sécurise les conversations entre les serveurs de messagerie (ce qui explique pourquoi il est appelé sécurité de la couche de transport). 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 (« end to end ») depuis l'origine du message jusqu'au client de messagerie du destinataire, encapsulant le corps du message.
S/MIME chiffre le corps du message avec la clé publique du destinataire. Le corps ne peut pas être décodé sans la clé privée du destinataire — pas par une « personne du milieu » comme votre FAI, SparkPost ou le serveur de messagerie du destinataire.
La clé privée n'est jamais divulguée ; elle est gardée en possession exclusive du destinataire. Le message crypté voyage sur Internet jusqu'au serveur de messagerie récepteur. Lorsqu'il arrive dans la boîte de réception du destinataire, il est (généralement automatiquement) décrypté avec sa clé privée et devient lisible.
Quelques pièges S/MIME dont il faut être conscient :
S/MIME le chiffrement a pour effet secondaire d'empêcher la numérisation des messages entrants par le serveur pour détecter les logiciels malveillants, car la charge utile du message est sous forme cryptée et donc indétectable.
Notez que l'entête des messages (headers) (De :, À :, Sujet : etc.) ne sont pas cryptées, donc le contenu de la ligne de sujet doit être créé en tenant compte de cela.
Signature – authentification
S/MIME offre également au destinataire la possibilité de vérifier que l'identité de l'expéditeur du message correspond à ce qu'il prétend être.
L'e-mail de l'expéditeur comporte un certificat joint qui, un peu comme le certificat d'un site sécurisé, peut être retracé jusqu'à une autorité d'émission. Pour une description complète du processus de signature, voir le S/MIME signing process PDF.
Nous adopterons l'approche consistant à signer le courrier en premier, puis à le chiffrer, de sorte que le processus se présente ainsi.
Non-répudiation
Un autre avantage utile pour le destinataire résultant de la signature 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 », le message reçu montre que le certificat de l'expéditeur a bien été utilisé.
Intégrité du message
Le processus de signature crée une empreinte du message source en clair (appelée condensé de message), chiffre le condensé à l'aide de la clé privée de l'expéditeur et l'intègre dans le message livré. Le client de messagerie du destinataire peut détecter si le corps du message a été altéré.
Vous pourriez dire, « Je pensais que DKIM me donnait des vérifications d'intégrité du message ! » Eh bien oui, DKIM fournit des vérifications d'intégrité du corps du message et de l'en-tête du message - garanties anti-altération. Cependant, l'échec de DKIM (ou son absence) ne provoquera généralement pas que le message entrant soit marqué comme complètement invalide …à moins qu'une politique DMARC de p=reject soit en place (voir notre article de blog DMARC: How to Protect Your Email Reputation). 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 montrera en évidence 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 fonctionnalité de la couche de présentation qui peut fonctionner entre deux utilisateurs finaux de courriel (avec des certificats/clefs valides) sans aucune action de l'admin du courriel. S/MIME fournit chiffrement et signature et est personnel à chaque utilisateur.
S/MIME est lié à l'adresse complète de l'expéditeur (partie locale et partie du domaine), donc, par exemple, alice@bigcorp.com et bob@bigcorp.com auraient besoin de certificats différents. En revanche, DKIM valide que l'e-mail provient du domaine signataire. DKIM est tout un sujet en soi ; cet article est un bon point de départ.
DKIM et DMARC configuration est effectuée par votre admin e-mail (en travaillant sur le serveur de messagerie et les enregistrements DNS). Une fois configurés, ils sont actifs pour les domaines, plutôt que pour des utilisateurs individuels.
La version courte :
Le chiffrement vous offre la confidentialité de vos messages.
La signature vous offre l'authentification (de l'expéditeur), la non-répudiation de l'origine et les vérifications de l'intégrité du message.
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 juridiquement important, 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 destinataire.
La partie « opportuniste » signifie toutefois que si le serveur d'envoi ne peut pas négocier une connexion sécurisée, nous enverrons le courrier en texte clair. Ce n'est pas convenable si vous souhaitez forcer le message à être sécurisé de bout en bout. Vous pouvez jeter un œil à les fournisseurs de messagerie qui revendiquent le support TLS et ceux qui le font réellement. Supposons que le serveur du destinataire supporte TLS, votre message est sécurisé de cette manière :
TLS sécurise les conversations entre les serveurs de messagerie (ce qui explique pourquoi il est appelé sécurité de la couche de transport). 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 (« end to end ») depuis l'origine du message jusqu'au client de messagerie du destinataire, encapsulant le corps du message.
S/MIME chiffre le corps du message avec la clé publique du destinataire. Le corps ne peut pas être décodé sans la clé privée du destinataire — pas par une « personne du milieu » comme votre FAI, SparkPost ou le serveur de messagerie du destinataire.
La clé privée n'est jamais divulguée ; elle est gardée en possession exclusive du destinataire. Le message crypté voyage sur Internet jusqu'au serveur de messagerie récepteur. Lorsqu'il arrive dans la boîte de réception du destinataire, il est (généralement automatiquement) décrypté avec sa clé privée et devient lisible.
Quelques pièges S/MIME dont il faut être conscient :
S/MIME le chiffrement a pour effet secondaire d'empêcher la numérisation des messages entrants par le serveur pour détecter les logiciels malveillants, car la charge utile du message est sous forme cryptée et donc indétectable.
Notez que l'entête des messages (headers) (De :, À :, Sujet : etc.) ne sont pas cryptées, donc le contenu de la ligne de sujet doit être créé en tenant compte de cela.
Signature – authentification
S/MIME offre également au destinataire la possibilité de vérifier que l'identité de l'expéditeur du message correspond à ce qu'il prétend être.
L'e-mail de l'expéditeur comporte un certificat joint qui, un peu comme le certificat d'un site sécurisé, peut être retracé jusqu'à une autorité d'émission. Pour une description complète du processus de signature, voir le S/MIME signing process PDF.
Nous adopterons l'approche consistant à signer le courrier en premier, puis à le chiffrer, de sorte que le processus se présente ainsi.
Non-répudiation
Un autre avantage utile pour le destinataire résultant de la signature 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 », le message reçu montre que le certificat de l'expéditeur a bien été utilisé.
Intégrité du message
Le processus de signature crée une empreinte du message source en clair (appelée condensé de message), chiffre le condensé à l'aide de la clé privée de l'expéditeur et l'intègre dans le message livré. Le client de messagerie du destinataire peut détecter si le corps du message a été altéré.
Vous pourriez dire, « Je pensais que DKIM me donnait des vérifications d'intégrité du message ! » Eh bien oui, DKIM fournit des vérifications d'intégrité du corps du message et de l'en-tête du message - garanties anti-altération. Cependant, l'échec de DKIM (ou son absence) ne provoquera généralement pas que le message entrant soit marqué comme complètement invalide …à moins qu'une politique DMARC de p=reject soit en place (voir notre article de blog DMARC: How to Protect Your Email Reputation). 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 montrera en évidence 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 fonctionnalité de la couche de présentation qui peut fonctionner entre deux utilisateurs finaux de courriel (avec des certificats/clefs valides) sans aucune action de l'admin du courriel. S/MIME fournit chiffrement et signature et est personnel à chaque utilisateur.
S/MIME est lié à l'adresse complète de l'expéditeur (partie locale et partie du domaine), donc, par exemple, alice@bigcorp.com et bob@bigcorp.com auraient besoin de certificats différents. En revanche, DKIM valide que l'e-mail provient du domaine signataire. DKIM est tout un sujet en soi ; cet article est un bon point de départ.
DKIM et DMARC configuration est effectuée par votre admin e-mail (en travaillant sur le serveur de messagerie et les enregistrements DNS). Une fois configurés, ils sont actifs pour les domaines, plutôt que pour des utilisateurs individuels.
La version courte :
Le chiffrement vous offre la confidentialité de vos messages.
La signature vous offre l'authentification (de l'expéditeur), la non-répudiation de l'origine et les vérifications de l'intégrité du message.
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 juridiquement important, 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 destinataire.
La partie « opportuniste » signifie toutefois que si le serveur d'envoi ne peut pas négocier une connexion sécurisée, nous enverrons le courrier en texte clair. Ce n'est pas convenable si vous souhaitez forcer le message à être sécurisé de bout en bout. Vous pouvez jeter un œil à les fournisseurs de messagerie qui revendiquent le support TLS et ceux qui le font réellement. Supposons que le serveur du destinataire supporte TLS, votre message est sécurisé de cette manière :
TLS sécurise les conversations entre les serveurs de messagerie (ce qui explique pourquoi il est appelé sécurité de la couche de transport). 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 (« end to end ») depuis l'origine du message jusqu'au client de messagerie du destinataire, encapsulant le corps du message.
S/MIME chiffre le corps du message avec la clé publique du destinataire. Le corps ne peut pas être décodé sans la clé privée du destinataire — pas par une « personne du milieu » comme votre FAI, SparkPost ou le serveur de messagerie du destinataire.
La clé privée n'est jamais divulguée ; elle est gardée en possession exclusive du destinataire. Le message crypté voyage sur Internet jusqu'au serveur de messagerie récepteur. Lorsqu'il arrive dans la boîte de réception du destinataire, il est (généralement automatiquement) décrypté avec sa clé privée et devient lisible.
Quelques pièges S/MIME dont il faut être conscient :
S/MIME le chiffrement a pour effet secondaire d'empêcher la numérisation des messages entrants par le serveur pour détecter les logiciels malveillants, car la charge utile du message est sous forme cryptée et donc indétectable.
Notez que l'entête des messages (headers) (De :, À :, Sujet : etc.) ne sont pas cryptées, donc le contenu de la ligne de sujet doit être créé en tenant compte de cela.
Signature – authentification
S/MIME offre également au destinataire la possibilité de vérifier que l'identité de l'expéditeur du message correspond à ce qu'il prétend être.
L'e-mail de l'expéditeur comporte un certificat joint qui, un peu comme le certificat d'un site sécurisé, peut être retracé jusqu'à une autorité d'émission. Pour une description complète du processus de signature, voir le S/MIME signing process PDF.
Nous adopterons l'approche consistant à signer le courrier en premier, puis à le chiffrer, de sorte que le processus se présente ainsi.
Non-répudiation
Un autre avantage utile pour le destinataire résultant de la signature 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 », le message reçu montre que le certificat de l'expéditeur a bien été utilisé.
Intégrité du message
Le processus de signature crée une empreinte du message source en clair (appelée condensé de message), chiffre le condensé à l'aide de la clé privée de l'expéditeur et l'intègre dans le message livré. Le client de messagerie du destinataire peut détecter si le corps du message a été altéré.
Vous pourriez dire, « Je pensais que DKIM me donnait des vérifications d'intégrité du message ! » Eh bien oui, DKIM fournit des vérifications d'intégrité du corps du message et de l'en-tête du message - garanties anti-altération. Cependant, l'échec de DKIM (ou son absence) ne provoquera généralement pas que le message entrant soit marqué comme complètement invalide …à moins qu'une politique DMARC de p=reject soit en place (voir notre article de blog DMARC: How to Protect Your Email Reputation). 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 montrera en évidence 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 fonctionnalité de la couche de présentation qui peut fonctionner entre deux utilisateurs finaux de courriel (avec des certificats/clefs valides) sans aucune action de l'admin du courriel. S/MIME fournit chiffrement et signature et est personnel à chaque utilisateur.
S/MIME est lié à l'adresse complète de l'expéditeur (partie locale et partie du domaine), donc, par exemple, alice@bigcorp.com et bob@bigcorp.com auraient besoin de certificats différents. En revanche, DKIM valide que l'e-mail provient du domaine signataire. DKIM est tout un sujet en soi ; cet article est un bon point de départ.
DKIM et DMARC configuration est effectuée par votre admin e-mail (en travaillant sur le serveur de messagerie et les enregistrements DNS). Une fois configurés, ils sont actifs pour les domaines, plutôt que pour des utilisateurs individuels.
Comment cela se rapporte-t-il à SparkPost?
Les systèmes de messagerie de personne à personne, tels que Microsoft Exchange Server, ont longtemps pris en charge S/MIME.
Si vous utilisez SparkPost pour envoyer à des destinataires spécifiques avec des clients de messagerie qui peuvent lire S/MIME, alors il peut être judicieux de signer vos messages avec S/MIME. La signature S/MIME ajoute une garantie supplémentaire que le message provient effectivement de vous (ou de votre système) et n'a pas été altéré, ce qui peut être précieux dans certains cas d'utilisation. Tout ce dont vous avez besoin pour cela est votre propre clé et un logiciel gratuit que nous démontrerons dans la partie 2 de cet article.
Utiliser le chiffrement S/MIME est un choix distinct à faire. Vous aurez besoin de la clé publique de chacun de vos destinataires. L'obtenir pourrait être aussi simple que de leur demander de vous envoyer (ou à votre application) un email signé. Nous explorerons un outil pratique pour envoyer des courriers signés et chiffrés S/MIME via SparkPost dans un article de suivi.
Les systèmes de messagerie de personne à personne, tels que Microsoft Exchange Server, ont longtemps pris en charge S/MIME.
Si vous utilisez SparkPost pour envoyer à des destinataires spécifiques avec des clients de messagerie qui peuvent lire S/MIME, alors il peut être judicieux de signer vos messages avec S/MIME. La signature S/MIME ajoute une garantie supplémentaire que le message provient effectivement de vous (ou de votre système) et n'a pas été altéré, ce qui peut être précieux dans certains cas d'utilisation. Tout ce dont vous avez besoin pour cela est votre propre clé et un logiciel gratuit que nous démontrerons dans la partie 2 de cet article.
Utiliser le chiffrement S/MIME est un choix distinct à faire. Vous aurez besoin de la clé publique de chacun de vos destinataires. L'obtenir pourrait être aussi simple que de leur demander de vous envoyer (ou à votre application) un email signé. Nous explorerons un outil pratique pour envoyer des courriers signés et chiffrés S/MIME via SparkPost dans un article de suivi.
Les systèmes de messagerie de personne à personne, tels que Microsoft Exchange Server, ont longtemps pris en charge S/MIME.
Si vous utilisez SparkPost pour envoyer à des destinataires spécifiques avec des clients de messagerie qui peuvent lire S/MIME, alors il peut être judicieux de signer vos messages avec S/MIME. La signature S/MIME ajoute une garantie supplémentaire que le message provient effectivement de vous (ou de votre système) et n'a pas été altéré, ce qui peut être précieux dans certains cas d'utilisation. Tout ce dont vous avez besoin pour cela est votre propre clé et un logiciel gratuit que nous démontrerons dans la partie 2 de cet article.
Utiliser le chiffrement S/MIME est un choix distinct à faire. Vous aurez besoin de la clé publique de chacun de vos destinataires. L'obtenir pourrait être aussi simple que de leur demander de vous envoyer (ou à votre application) un email signé. Nous explorerons un outil pratique pour envoyer des courriers signés et chiffrés S/MIME via SparkPost dans un article de suivi.
Quels clients supportent S/MIME ?
Consumer Gmail
Le client Web Gmail ordinaire affiche les signatures des courriels entrants (voir ci-dessous), mais il n'est pas configuré pour contenir votre clé privée afin de lire les messages crypté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 du point de vue de la sécurité.
Je n'ai pas pu faire en sorte que Yahoo! Mail décode les signatures dans les messages.
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 d'entreprise hébergé
Pour les organisations ayant des mails hébergés, Microsoft Office 365 et G Suite Enterprise offrent un support S/MIME.
Clients mail Outlook
Microsoft Outlook basé sur un 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 confiance / Paramètres du Centre de confiance / Sécurité du courrier / 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 supporte S/MIME sur tous ceux-ci. Voici comment un message s'affiche sur Mac. L'icône "enveloppe scellée" indique que le message est signé et le cadenas indique qu'il a été crypté.
Cliquer sur l'enveloppe/cadenas affiche des informations 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
Mac Mail
Mac Mail supporte aussi S/MIME. Il s'appuie sur votre trousseau Mac pour contenir vos clés.
iOS Mail
Tout d'abord, importez le certificat de votre compte email comme ceci, puis vous pouvez voir les emails signés et cryptés S/MIME. Ils ne paraissent vraiment pas différents sur l'écran de visualisation.
Android
Certains appareils et applications supportent S/MIME ; il y a beaucoup de variété. Samsung a un guide.
Consumer Gmail
Le client Web Gmail ordinaire affiche les signatures des courriels entrants (voir ci-dessous), mais il n'est pas configuré pour contenir votre clé privée afin de lire les messages crypté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 du point de vue de la sécurité.
Je n'ai pas pu faire en sorte que Yahoo! Mail décode les signatures dans les messages.
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 d'entreprise hébergé
Pour les organisations ayant des mails hébergés, Microsoft Office 365 et G Suite Enterprise offrent un support S/MIME.
Clients mail Outlook
Microsoft Outlook basé sur un 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 confiance / Paramètres du Centre de confiance / Sécurité du courrier / 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 supporte S/MIME sur tous ceux-ci. Voici comment un message s'affiche sur Mac. L'icône "enveloppe scellée" indique que le message est signé et le cadenas indique qu'il a été crypté.
Cliquer sur l'enveloppe/cadenas affiche des informations 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
Mac Mail
Mac Mail supporte aussi S/MIME. Il s'appuie sur votre trousseau Mac pour contenir vos clés.
iOS Mail
Tout d'abord, importez le certificat de votre compte email comme ceci, puis vous pouvez voir les emails signés et cryptés S/MIME. Ils ne paraissent vraiment pas différents sur l'écran de visualisation.
Android
Certains appareils et applications supportent S/MIME ; il y a beaucoup de variété. Samsung a un guide.
Consumer Gmail
Le client Web Gmail ordinaire affiche les signatures des courriels entrants (voir ci-dessous), mais il n'est pas configuré pour contenir votre clé privée afin de lire les messages crypté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 du point de vue de la sécurité.
Je n'ai pas pu faire en sorte que Yahoo! Mail décode les signatures dans les messages.
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 d'entreprise hébergé
Pour les organisations ayant des mails hébergés, Microsoft Office 365 et G Suite Enterprise offrent un support S/MIME.
Clients mail Outlook
Microsoft Outlook basé sur un 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 confiance / Paramètres du Centre de confiance / Sécurité du courrier / 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 supporte S/MIME sur tous ceux-ci. Voici comment un message s'affiche sur Mac. L'icône "enveloppe scellée" indique que le message est signé et le cadenas indique qu'il a été crypté.
Cliquer sur l'enveloppe/cadenas affiche des informations 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
Mac Mail
Mac Mail supporte aussi S/MIME. Il s'appuie sur votre trousseau Mac pour contenir vos clés.
iOS Mail
Tout d'abord, importez le certificat de votre compte email comme ceci, puis vous pouvez voir les emails signés et cryptés S/MIME. Ils ne paraissent vraiment pas différents sur l'écran de visualisation.
Android
Certains appareils et applications supportent S/MIME ; il y a beaucoup de variété. Samsung a un guide.
Enfin…
C'est 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 chiffrement S/MIME aux messages que vous envoyez via SparkPost.
Lecture complé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é résolue, consultez le site officiel EFAIL. D'autres explications faciles à suivre sont disponibles sur la page wiki EFAIL et dans le blog de CipherMail EFAIL : Qu'est-ce qui est vulnérable, PGP, S/MIME ou votre client de messagerie ?.
C'est 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 chiffrement S/MIME aux messages que vous envoyez via SparkPost.
Lecture complé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é résolue, consultez le site officiel EFAIL. D'autres explications faciles à suivre sont disponibles sur la page wiki EFAIL et dans le blog de CipherMail EFAIL : Qu'est-ce qui est vulnérable, PGP, S/MIME ou votre client de messagerie ?.
C'est 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 chiffrement S/MIME aux messages que vous envoyez via SparkPost.
Lecture complé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é résolue, consultez le site officiel EFAIL. D'autres explications faciles à suivre sont disponibles sur la page wiki EFAIL et dans le blog de CipherMail EFAIL : Qu'est-ce qui est vulnérable, PGP, S/MIME ou votre client de messagerie ?.
