Digital Snake Oil Is Still Snake Oil


In the wake of Edward Snowden's revelations about the US Government's domestic (and international) spying activity, there has been (understandably) an increase in the general public's interest in encryption and secure communications. A number of good pieces of software have resulted from this increased interest (e.g., Signal, Threema, Telegram[1]), but some unscrupulous companies have also sought to take advantage both of the public's interest and of the public's lack of knowledge. Some forms of communication are inherently insecure, and any company attempting to sell you a "secure" version should be treated with extreme skepticism.

Email

Email is an insecure means of communication. Full stop. While it is true that email may be secured, to some degree, by SSL/TLS, it is generally not. Furthermore, even if you secure your connection to your email provider, there is no guarantee that all of the connections along the route will be secure or that your recipient's connection to his email provider will be secure. Let's take a simple example:

  • A wishes to send an email to B. A has email [email protected] and B has email [email protected].
  • In order to send an email, A must connect to his email provider (i.e., example.com) and send an email via their outgoing server.
    • The connection between A and example.com may be secured by SSL/TLS, or it may not. The email specification doesn't really care.
  • After A sends his email to example.com's outgoing server, that server forwards the email either directly to example.net's incoming server (as the intended recipient is an email address on example.net) or via a number of intermediaries to example.net's incoming server.
    • If any of the connections between example.com's outgoing server and example.net's incoming server are not secured by SSL/TLS, then the email sent by A will be transmitted over that unsecured connection as plain text (i.e., anyone monitoring that connection will be able to read the email contents).
  • Upon receipt of the email, example.net's incoming server directs the email to B.
    • The connection between B and example.net may be secured by SSL/TLS, or it may not. Again, the email specification doesn't care.

As you can see, there are at least three connections involved (and possibly several more) all of which must be secured by SSL/TLS or the email message can be intercepted. However, those connections are not the only security concern. Messages are often stored on email servers (e.g., when using IMAP) and that data at rest[2] must also be encrypted or else anyone with access to the server can read the contents of every stored message.

Essentially, email should be treated as less secure than a posted letter. At least with the letter it generally passes only through postal employee hands (employees who are usually monitored by video surveillance) and exists as a single entity. With email, your message may pass through a dozen "hands" and likely exists as at least four copies (i.e., on your computer, on your provider's outgoing server, on the recipient's provider's incoming server, and on the recipient's computer), and usually as many more (e.g., your smartphone, your tablet, and your laptop may each have a copy).

Secure Email

There is, essentially, no such thing as secure email. As stated, supra, email is an insecure form of communication. The content of an email may be secured (e.g., you can encrypt the body text before sending the message), but the email itself is not secure. Is it impossible to secure email? Of course not, but even 'secure' email shouldn't be used to transmit confidential information. Using email to send properly encrypted content is perfectly safe, but when transmitting properly encrypted content the means of transmission matters relatively little (because the security of the content is based on the encryption, not the security of the means of transmission).

One minor exception is when using a host that encrypts all connections to/from its servers (i.e., data in transit) and encrypts stored messages (i.e., data at rest) and both sender and recipient are using that host. In essence, if example.com encrypts data in transit and data at rest (and doesn't allow unencrypted connections), then sending a message from [email protected] to [email protected] should be secure[3]. Of course, this doesn't mean you have "secure email", it just means that a limited subset of the emails you send will be protected by encryption (i.e., those that do not leave your domain)[4] and, therefore, relatively secure.

Secure Communications

If you need to communicate securely, make sure that you are using a secure means of communication. Tautological, sure, but it seems that it does not go without saying. There are plenty of secure means of communication available; email is not one of them.


  1. While Telegram's encryption is not perfect, it is sufficiently good to avoid most snooping. ↩︎

  2. The email when travelling from A to B is said to be "in transit"; once the email arrives on example.net's servers (and as it resides in A's outgoing mailbox on example.com's servers) it is said to be "at rest". ↩︎

  3. Notably, the same holds if sending from [email protected] to [email protected] if and only if an additional requirement is met: the connection between example.com and example.net is encrypted. ↩︎

  4. All of the companies for which I make IT decisions host with the same provider, and I have the various accounts configured to require encryption. I trust that emails sent within or amongst these organizations are secure (as they all traverse only secured connections that require encryption), but I still do not consider email to be a secure means of communication even given this setup. ↩︎