S/MIME is a long-established method of sending encrypted, signed email, based on public Internet standards. We regularly come across requirements for S/MIME, particularly from regulated industries such as banking, health, and finance. S/MIME often is required when communicating between businesses and government agencies, for example.

Another secure mail standard, PGP (amusingly named as “Pretty Good Vie privée”), is used more for secure person-to-person communications. It’s less popular now because the consumer versions of popular web-based email clients such as Gmail and Outlook/Hotmail aren’t able to display encrypted mail. That’s one reason much person-to-person communication that requires privacy has moved to platforms such as WhatsApp (and many others) that offer native, end-to-end encryption.

Both PGP and S/MIME require a mail client that can use keys and certificates. Many desktop and mobile clients, including Apple Mail, Microsoft Outlook, and Mozilla Thunderbird fit the bill, as do business versions of some web clients such as Microsoft Office 365. Setting up the keys takes work, but many organizations still consider it worthwhile, despite recent divulgations de vulnérabilité requiring remèdes to block loading of remote content.

S/MIME has been around since 1995 and gone through several revisions; the current version is covered by RFC 5751. It requires exchange of public keys, a non-trivial task that often requires the support of an IT team or similar resource. This is wici commercial solutions from companies such as SparkPost partners Virtru and Echoworkx come in, making security easier for person-to-person business mailing (see our Mode d'emploi de SparkPost/Echoworkx for more information).

Cela dit, examinons un peu 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 cryptage permet de protéger la confidentialité des messages.

• La signature permet l'authentification (de l'expéditeur), la non-répudiation de l'origine et le contrôle de l'intégrité du message.

• S/MIME fonctionne différemment de DKIM et DMARC et peut coexister avec eux.

Vie privée
If your messages contain nothing personal, private, or legally important, then you probably won’t need to think about S/MIME. Modern email delivery systems such as SparkPost already use “TLS opportuniste” to secure the message transport from sending server to recipient server.

Le “opportunistic” part does mean however that if the sending server can’t negotiate a secure connection, we’ll send the mail in plain text. This isn’t suitable if you want to force the message to be secure all the way. You can take a peek at quels fournisseurs de boîtes aux lettres prétendent supporter TLS and which en fait. Assuming the recipient’s server does support TLS, your message is secured comme ceci:

TLS sécurise les conversations entre les serveurs de messagerie (c'est pourquoi on l'appelle Transport Layer Security). MIME (y compris S/MIME) s'occupe du contenu des messages et de son traitement, et peut être considéré comme faisant partie de la "couche de présentation".

S/MIME secures the message content all the way (“end to end”) from the message origin à la recipient mail client, encapsulating the message body.

S/MIME crypte le corps du message avec la clé publique du destinataire. Le corps du message ne peut être décodé sans la clé privée du destinataire, ni par une "personne au milieu" telle que votre FAI, SparkPost ou le serveur de messagerie du destinataire.

La clé privée n'est jamais divulguée ; elle est en possession exclusive du destinataire. Le message crypté transite par l'internet jusqu'au serveur de messagerie de réception. Lorsqu'il arrive sur le site inbox du destinataire, il est (généralement automatiquement) décrypté à l'aide de sa clé privée et devient lisible.

Quelques problèmes de S/MIME à connaître :

Le cryptage S/MIME a pour effet secondaire d'empêcher la recherche de logiciels malveillants dans les messages entrants sur le serveur, car la charge utile du message est cryptée et ne peut donc pas être identifiée.

Note that the message en-têtes (From:, To:, Subject: etc) are not encrypted, so the subject-line content needs to be created with that in mind.

Signature - authentification
S/MIME also provides the recipient the ability to check that the identity of the message sender est celui qu'il prétend être.

Le sender’s email has a certificate attached, which, rather like the certificate on a secure website, can be traced back to an issuing authority. Tici’s a full description of the signing process ici.

Nous allons d'abord signer le courrier, puis le crypter, de sorte que le processus ressemble à ceci.

Non-répudiation
Another useful benefit of signing à la recipient is non-repudiation of origin. Consider a situation wici an email message is used to approve a contract. The recipient gets the contract in a message from the sender. If the sender later tries to say, “Nope, I never sent that message to you”, then the received message shows that the sender’s certificate was in fact used.

Intégrité du message
The signing process creates a fingerprint of the plain source message (known as a message digest), encrypts the digest using the sender’s private key, and includes it in the delivered message. The recipient’s mail client can tell if the message body is tampered with.

Perhaps you might say, “I thought DKIM gives me message integrity checks!” Well yes, DKIM provides message body and message header integrity checks – anti-tampering guarantees. However, DKIM failure (or absence) will not usually cause the incoming message to be marked as completely invalid, …unless a DMARC policy of `p=reject` is in play (more on DMARC here). DKIM is one factor of many used by the ISP for reliable assignment of reputation to a domain and is, of course, an essential part of your messaging stack.

Votre client de messagerie vous indiquera clairement si un message S/MIME échoue aux contrôles de signature :

Résumé : de bout en bout (S/MIME) contre de serveur à serveur (DKIM, DMARC, TLS)
S/MIME is a presentation-layer capability that can work between two email end-users (with valid certificates/keys) without any action by the email admin. S/MIME provides encryption and signing and is personal to each user.

S/MIME is tied to the full sending address (local part and domain part), so, for example, alice@bigcorp.com and bob@bigcorp.com would need to have different certificates. In contrast, DKIM validates the email is coming from the signing domain. DKIM is a whole subject in itself; cet article is a good place to start.

La configuration de DKIM et DMARC est effectuée par votre administrateur de messagerie (qui travaille sur le serveur de messagerie et les enregistrements DNS). Une fois configurés, ils sont actifs pour les domaines, et non pour les utilisateurs individuels.

Quel est le lien avec SparkPost ?

Mail systems for person-to-person messaging, such as Microsoft Exchange Server, have a longtemps supporté S/MIME.

Si vous utilisez SparkPost pour envoyer des messages à des destinataires spécifiques avec des clients de messagerie qui peuvent lire S/MIME, il peut être judicieux de signer S/MIME vos messages. La signature S/MIME apporte une garantie supplémentaire que le message provient bien de toi (ou de ton système) et qu'il n'a pas été falsifié, ce qui peut être utile dans certains cas. Tout ce dont vous avez besoin pour cela est votre propre clé et un logiciel gratuit dont nous ferons la démonstration dans la deuxième partie de cet article.

L'utilisation du cryptage S/MIME est un choix distinct à faire. Vous aurez besoin de la clé publique de chacun de vos destinataires. Pour l'obtenir, il suffit de leur demander de vous envoyer (ou à votre application) un courriel signé. Nous explorerons un outil pratique pour envoyer du courrier signé et crypté S/MIME par le biais de SparkPost dans un post de suivi.

Quels clients prennent en charge S/MIME ?

Consommateur Gmail
The ordinary Gmail web client displays incoming mail signatures (see below), but it’s not set up to hold your private key to read encrypted messages. Even if that were possible via third-party plugins, uploading your private key is not a great idea from a security standpoint.

Je n'ai pas réussi à faire en sorte que Yahoo ! Mail décode les signatures dans les messages.

La version grand public des comptes Microsoft Outlook/Hotmail vous avertit de la présence d'une signature S/MIME, mais ne vous donne pas un accès complet pour visualiser ou vérifier le certificat.

Courrier professionnel hébergé
For organizations with hosted mail, Microsoft Office 365 and G Suite Enterprise have S/MIME support.

Clients de messagerie Outlook
Client-based Microsoft Outlook (e.g. 2010 for Windows) works:

En cliquant sur les icônes, vous obtenez 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é de la messagerie / Importation / Exportation.

Thunderbird - multiplateforme et gratuit
If you’re looking for a free client, Mozilla Thunderbird fits the bill. It’s available on PC, Mac, and Linux, and supports S/MIME across all of these. Here’s how a message looks on Mac. The “sealed envelope” icon indicates the message is signed, and the padlock indicates it was encrypted.

En cliquant sur l'enveloppe/le cadenas, on obtient des informations sur le message :

Thunderbird has its own key store, accessed in similar ways on each platform:
Mac via Preferences / Advanced / Certificates / Manage Certificates
PC: menu (“hamburger” top right), Advanced / Certificates / Manage Certificates
Linux: menu (“hamburger” top right), Preferences / Advanced / Manage Certificates

Mac Mail
Mac Mail also supports S/MIME. It relies on your Mac keychain to hold your keys.

iOS Mail
Firstly, import your email account’s certificate like this, then you can view S/MIME signed and encrypted emails. They don’t really look any different on the viewing screen.

Android
Quelques devices and apps support S/MIME; there’s a lot of variety out there. Samsung has a guide.

Enfin...

That’s our quick overview of the practical uses of S/MIME. If you want to get your own mail certificates, there’s a list of providers here. I found Comodo works well (free for non-commercial use – open this in Firefox, not Chrome).

Dans la deuxième partie, nous verrons comment appliquer la signature et le cryptage S/MIME aux messages que vous livrez via SparkPost.

Autres lectures
Microsoft has a good introductory article on S/MIME here.

For more info on the EFAIL vulnerability and how it’s been addressed, this is the definitive site. Other easy-to-follow explanations are here and here.