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 Integritet”), 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 avslöjande av sårbarheter requiring rättsmedel 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 whär commercial solutions from companies such as SparkPost partners Virtru and Echoworkx come in, making security easier for person-to-person business mailing (see our SparkPost/Echoworkx hur man gör for more information).

Med det sagt, låt oss gräva lite djupare i gamla vanliga S/MIME och se vad vi kan göra med det.

Varför skulle jag bry mig?

Den korta versionen:

• Kryptering ger dig meddelandeskydd.

• Signering ger autentisering (av avsändaren), icke-avvisande av ursprung och kontroll av meddelandets integritet.

• S/MIME fungerar annorlunda än DKIM och DMARC och kan samexistera med dem.

Integritet
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 “opportunistisk TLS” to secure the message transport from sending server to recipient server.

Den “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 vilka brevlådeföretag som hävdar att de stöder TLS and which faktiskt gör. Assuming the recipient’s server does support TLS, your message is secured som detta:

TLS säkrar konversationerna mellan e-postservrar (vilket är anledningen till att det kallas Transport Layer Security). MIME (inklusive S/MIME) handlar om meddelandets innehåll och hur det behandlas, och kan ses som en del av "presentationslagret".

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

S/MIME krypterar meddelandetexten med mottagarens publika nyckel. Texten kan inte avkodas utan mottagarens privata nyckel - inte av någon "person i mitten" som din Internetleverantör, SparkPost eller mottagarens e-postserver.

Den privata nyckeln lämnas aldrig ut utan behålls endast av mottagaren. Det krypterade meddelandet skickas via Internet till den mottagande e-postservern. När det landar i mottagarens inbox dekrypteras det (vanligtvis automatiskt) med mottagarens privata nyckel och blir läsbart.

Några S/MIME gotchas att vara medveten om:

S/MIME-kryptering har en sidoeffekt som förhindrar serverbaserad skanning av inkommande meddelanden efter skadlig kod eftersom meddelandets nyttolast är krypterad och därför inte kan identifieras.

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

Signering - autentisering
S/MIME also provides the recipient the ability to check that the identity of the message sender är den de utger sig för att vara.

Den sender’s email has a certificate attached, which, rather like the certificate on a secure website, can be traced back to an issuing authority. Thär’s a full description of the signing process här.

Vi väljer att först signera e-postmeddelandet och sedan kryptera det, så att processen ser ut på följande sätt.

Oavvislighet
Another useful benefit of signing till recipient is non-repudiation of origin. Consider a situation whär 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.

Meddelandeintegritet
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.

Din e-postklient visar dig på ett tydligt sätt om ett S/MIME-meddelande inte klarar signaturkontrollen:

Sammanfattning: end-to-end (S/MIME) vs server-to-server (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; denna artikel is a good place to start.

DKIM- och DMARC-konfigurationen görs av din e-postadministratör (som arbetar med e-postservern och DNS-posterna). När de har konfigurerats är de aktiva för domäner snarare än enskilda användare.

Hur hänger detta ihop med SparkPost?

Mail systems for person-to-person messaging, such as Microsoft Exchange Server, have stödde länge S/MIME.

Om du använder SparkPost för att skicka till specifika mottagare med e-postklienter som kan läsa S/MIME, kan det vara vettigt att S/MIME-signera dina meddelanden. S/MIME-signering ger ytterligare säkerhet om att meddelandet faktiskt kommer från dig (eller ditt system) och inte har manipulerats, vilket kan vara värdefullt i vissa användningsfall. Allt du behöver för detta är din egen nyckel och lite gratis programvara som vi kommer att visa i del 2 av denna artikel.

Att använda S/MIME-kryptering är ett separat val. Du behöver den publika nyckeln för var och en av dina mottagare. Det kan vara så enkelt som att låta dem skicka ett signerat e-postmeddelande till dig (eller din app). Vi kommer att utforska ett praktiskt verktyg för att skicka S/MIME-signerad och krypterad e-post via SparkPost i ett uppföljande inlägg.

Vilka klienter stöder S/MIME?

Konsument 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.

Jag kunde inte få Yahoo! Mail att avkoda signaturer i meddelanden överhuvudtaget.

Konsumentversionen av Microsoft Outlook/Hotmail-konton uppmärksammar dig på att det finns en S/MIME-signatur, men ger dig inte full åtkomst till att visa eller kontrollera certifikatet.

Hostad e-post från företag
For organizations with hosted mail, Microsoft Office 365 and G Suite Enterprise have S/MIME support.

Outlook e-postklienter
Client-based Microsoft Outlook (e.g. 2010 for Windows) works:

Om du klickar på ikonerna får du mer information:

I Outlook 2010 / Windows nås certifikatarkivet via Arkiv / Alternativ / Trust Center / Trust Center-inställningar / E-postsäkerhet / Importera / Exportera.

Thunderbird - plattformsoberoende och gratis
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.

Om du klickar på kuvertet/padlocken visas information om meddelandet:

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 E-post
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
Några devices and apps support S/MIME; there’s a lot of variety out there. Samsung has a guide.

Äntligen...

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).

I del 2 går vi igenom hur du använder S/MIME-signering och kryptering för meddelanden som du levererar via SparkPost.

Ytterligare information
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.