Did You Know? S/MIME is like SSL for Email Encryption

S/MIME is a popular technology for end-to-end email encryption and is analogous to PGP in the way that it works.  It is commonly available in most modern email programs and in many server-side email and WebMail encryption services like LuxSci SecureLine.

Folks are used to thinking about Internet security and encryption in terms of web site security. E.g. the “https://” that secures our everyday life working in our web browsers is the signal that SSL/TLS is being used to encrypt traffic between ourselves and the web server.  People are even becoming used to the fact that TLS (with SMTP) is also commonly used to secure the transport of email messages from server-to-server.

These are all good things!

S/MIME (like PGP) is different — it encrypts the email message before it is sent and the message stays encrypted until the recipient opens it.  It “doesn’t matter” how this message is transported to the recipient … its secure the whole way.[1]  But did you know that S/MIME is really just an application of the same SSL/TLS technology that secures your traffic to securing your messages?

[1] S/MIME (and PGP) do not secure your message headers (e.g. the subject, recipients, etc.), it only secures the message body and attachments.  So, the added security of SMTP over TLS does serve to protect those things that S/MIME does not protect.

How can S/MIME be SSL?

Well, it is not strictly SSL.  But it is conceptually SSL.  If we review how SSL works (see how in more detail) from 100 feet away:

1. Way ahead of time: The server is issued a certificate from a “universally trusted authority” for a web site.
2. You connect to the web site/server and “do the SSL dance” (your browser talking to the server):
   1. Get the server’s certificate
   2. Decide if its valid and you trust it
   3. Agree on cryptographic algorithms to use for message digests, symmetric encryption, etc.
   4. Agree on an encryption key for this session of secure dialog
3. You then talk to the server over this secure channel using the agreed-upon crypto

This works very well and is the fundamental way that traffic on Internet is currently secured.  Many bugs and flaws have been found (and will be found) in this and they have been and are fixed as fast as possible; its the best we have at the moment.

So — What does this have to do with S/MIME email encryption?

S/MIME works much like the above description of SSL, except there can be no “dialog” between client and server due to the time delay between sending and opening the message.

With S/MIME:

1. Way ahead of time: The recipient gets a certificate which can be from a “trusted authority”
   1. This certificate is exactly the same as an SSL certificate.  The difference lines in the fact that it is issued for an email address like “joe@domain.com” instead of a web site like “some-other-domain.com”.
   2. Also, people are usually less concerned about getting certificates for S/MIME from a universally trusted source — but the trust mechanisms are the same as they are for SSL.
2. The public part of the is recipient’s certificate is somehow communicated to the sender before the emailmessageis sent
   • This is the “hard part.”  It could be sent in another email, be published in DNS, available through the sender’s email service provider, etc.
3. The sender (actually his email system) constructs a secure message using S/MIME
   1. Pick cryptographic algorithms to use for message digests, symmetric encryption, etc.
      1. The choice of algorithms used here is exactly the same as those used for SSL/TLS.
   2. Choose an encryption key for the message
   3. Encrypt that encryption key using the recipient’s S/MIME certificate (so only the recipient can open it and thus open the meat of the message)
   4. Encrypt the message body and sign it using the chosen crypto.
   5. Format all that in an “S/MIME” way so that it becomes a regular email message and can be recognized by the recipient as S/MIME.
4. The encrypted message is sent.

Compare:

S/MIME is exactly like SSL/TLS in that:

1. They use the same kinds of certificates (x.509) to identify SSL servers and S/MIME recipients and to handle trust
2. They use the same kinds of cryptographic hashes (e.g. SHA1 or SHA256, etc.)
3. They use the same kinds of symmetric encryption functions  (e.g. AES256. etc.)
4. The symmetric encryption key is communicated to the recipient using the same the recipient’s public S/MIME key in an analogous way to how this happens with SSL/TLS.
5. Both mechanisms can encrypt your email in transit: however, TLS/SSL does a more complete job of this.

S/MIME differs from SSL/TLS in that:

1. There is no real-time dialog
   • This is a really important difference for security, as we will see in our next post.
2. The sender and recipient do not get to agree on what cryptographic algorithms are used as part of the sending process … the sender picks ones that will be compatible with the recipient’s S/MIME key and which the sender thinks are secure enough and compatible enough for use.
3. Senders usually place more implicit trust in recipient S/MIME keys than they do in the certificates offered by web sites
   • This is because there is much less of an issue with man-in-the-middle attacks with S/MIME due to the fact that these certificates are usually communicated out-of-band, before the message is sent.
4. S/MIME secures your messages at rest — while they are sitting around in email folders and backups (but only the bodies and attachments).

Hold On!

If S/MIME is so much like SSL (indeed the universal open source “openssl” library is often used for both SSL, TLS, and S/MIME), how secure is it?  Is S/MIME subject to any of the problems we have seen over the past years related to SSL/TLS?  E.g. BEAST, POODLE, HeartBleed, etc?  Should we worry or use PGP or something else instead?

See followup post: Can S/MIME be Trusted?