How well is email protected when travelling between companies?

A question was asked to us recently about the safety of email across companies, and it made us think that a more helpful way to answer this was not directly back to the person, but in an open way that might help other people to understand a little more about what happens when they hit “send” from their email account at work…

58%? That’s a great percentage!

A Facebook survey last year suggested that 58% of email servers supported encryption when receiving an email from Facebook. In terms we all understand, this means that 58% of those people could receive emails that were protected (by their own email servers) so only they could read the message.

Imagine putting the email in a box and sending it to someone else. An encrypted message is like the box getting locked on sending, and you opening the box with the key on receiving it. Feels pretty safe, right? An unencrypted message means the box got sent without any locks on, so the postman might have had a sneaky look. That feels less good.

Before we all agree that 58% sounds pretty great and start clapping, let’s take a glass-half-empty approach for a minute. That means 42% of email servers were receiving all their email in plain text. In other words, 42% of emails received had no protection, no lock on the box so to speak.

Now because the large email providers are better than average, the actual volume of email sent encrypted is better than 58%, BUT if you are CC’ing multiple organisations on business discussions the odds are good at least some of the recipients are getting it sent to them without any encryption. So your message is out there, in an open box.

One to keep in mind…

My passport to the internet

On the Internet ‘certificates’ are an indication you are who you say you are – like when you go to an airport and prove your identity with your passport.

Typically a certificate is issued to someone who can receive email at an administrative email address for a company, they then install it on the email server. However (back to the Facebook survey), only 30% of the email servers had a correct certificate and 28% of email servers had a certificate with incorrect details (usually the name).

The significant thing here is that Facebook will deliver your email to an email server with an incorrect certificate. Now don’t blame Facebook, they are better than most on these things. If they insisted on correct certificates, 28% of their emails would have failed. You can understand why they take a risk.

To play it out, the conversation might be something like this:

Alan’s mail server: “I have email for Barbara at Big Inc

Sneaky other mail server hiding in front of Barbara’s email: “I support encryption, I am Bad Corporation’s email server”

Alan’s mail server “Oh great, here is the email for Barbara at Big Inc encrypted for Bad Corporation”

Sneaky other mail server “I’ll be sure she gets it”

In web security accepting a certificate with the wrong name is classed as a serious security bug, as it may allow someone to break into your online banking (services which often use email for reseting account credentials).

In the email space accepting the wrong certificate is still often regarded as a ‘win’.

So your email was delivered to the email server encrypted (in the locked box), but it might have been received by a server belonging to an eavesdropper (like the postman delivering it to someone who happened to be stood at your front door at the time).

So, what does it mean?

Whilst the bulk of email is encrypted (locked in a box) when it is sent between email servers, there are no guarantees. So remember, it might be more like sending a postcard than a letter in a locked box.

It is usually trivial for anyone who can intercept network traffic between email servers to intercept the email, even when it is encrypted.

General email won’t become secure against active attacks any time soon.

Hardly anyone enforces good encryption behaviour, although the tools are widely available.

Companies that control their own email servers can co-operate to enforce stronger policies, but most don’t.

If you really must use email for sensitive correspondence, consider using a technology that encrypts the content of the messages (e.g. OpenPGP, S/MIME) so that the receiver gets visibility of any issues with the encryption, and you are not reliant on the existing email infrastructure which might not suitable for sensitive correspondence.

For a more technical article, this one is excellent.