Your Emails Are Not Secure! (And What You Can Do About It)

Your Emails Are Not Secure! (And What You Can Do About It)

What if I told you... I can read your emails? Now I have no interest in doing that, but there may be people out there who do. In  this article I'm going to help you stop them.

Email is a really old technology  that predates the internet as we know it. Back in those days it was more of an internal thing and  you had to be physically connected to someone's network in order to send them a message. If they had any idea back then how massive email would become, and that we would use it to  communicate across the globe using public networks, I'm sure they would have done a few things  differently.

The fundamental problem with email is that the standard method for message transmission  is plain text. Even when you've got images in your email those are being encoded into text and  transmitted as a series of characters. This is really not good because it means anyone in-between  you and the recipient can read that text if they so choose.

Think about how your email gets the  recipient - the different networks and corners of the internet that it passes through. It's a bit  like passing a note around in class and hoping nobody else decides to read it en route.

Obviously, this is no way for a modern  communication system to behave, so we've come up with ways of encrypting the data so that  other people can't read it. The catch is that all of this encryption is being retrofitted on top  of a shonky old plain text protocol. The default option is still just to send it in a form that  is clearly readable by third parties.

There are largely speaking two types of email encryption  being used. Well, there's a third... but it's cheating. Some vendors are offering what they're calling  "encrypted emails" but they just actually send you a link that you use to access their website. Basically, what they're doing is they're not using email at all. They're sending you a link to  the website and after that you're communicating via the website rather than via email. That's not  really solving the problem with email - it's just avoiding using email!

Message Encryption

The two types of actually  encrypted email are transport-based and message-based encryption. Message-based encryption  encrypts the email itself. This typically happens in your software before you send it. The  most common standards are Secure MIME and PGP. This is arguably the most secure method because  the email remains encrypted wherever ends up, and only the intended recipient should ever be able to  read it. It's also the biggest pain to setup, because in order for the recipient to be able to read it  they first have to exchange keys with the sender. This makes it useful in very specific cases, but a  nightmare to manage at scale.

Think about it. If you have two relatively small organisations, say each  with one hundred people, and each of those people can email any in the other, then that's like 10,000 key  exchanges before they can actually send any emails. There are systems to centrally manage this, but  once you centrally manage it you eat away at the supposed benefit of message-based encryption;  because now you've got a single point where things can be decrypted and you lose some  of the guaranteed person-to-person privacy.

You also have problems with things like antivirus. Because the message is encrypted, it can't be opened by a malware scanner, so you just have to  trust it's OK. The same goes for stamping things like a company's information on the bottom, which  in many cases is a legal requirement to include. You have to make sure it's added on the  client side before the user presses the send button, because you can't add it later. As a result, this message-based encryption is impractical for general use and only really works  in scenarios where the sender and the recipient have some kind of existing relationship, and an  IT department willing to support it.

Transport Encryption

Because of these shortcomings, most organisations  use transport-based encryption like TLS. This encrypts a connection between the email  servers, rather than encrypting the email itself. This is a lot easier to set up and protects  the email as it travels across the internet, which is usually what people are worried about. Because the encryption is from server to server there's no problem scanning for malware, because  once it arrives it's no longer encrypted. The downside is that if someone managed to steal  the message from the server or your mailbox they can now read it without any special decryption key.

This transport-based encryption can be implemented opportunistically, or it can be enforced. It used  to be that enforcement was the only option, so if you have a really old system the opportunistic  route might not exist. Realistically though, if you're running something that old then I suspect  security isn't a big concern for you... and I don't mean that as a compliment.

Opportunistic encryption  is basically a conversation where the sending server connects to the receiving server in plain  text. The receiving server then says "Hey! I can do encryption. Should we do encryption?" If the sending  server replies "Yeah. I can do encryption, too. Let's do encryption!" then the connection gets upgraded to  a secure one. If either party doesn't support this type of encryption then the message just gets sent  as plain text, because that's the method guaranteed to work for anyone.

This approach is usually the  standard nowadays, as most modern systems will support opportunistic encryption. For some use  cases, it's not enough. If you're communicating with a bank, for example, they may insist on  enforced encryption. They're probably not going to accept that hey, you tried. They're going to want  a guarantee.

Enforced encryption happens when the sending and receiving parties agree that they will  only transmit messages over a secure connection. If one server says they can't do the encryption then  the connection gets terminated. This requires a bit of forward planning. Usually your IT team  need to talk to their IT team to set it up. It is relatively straightforward, though; as it  just needs to be configured server to server. You don't need to set it up between every single  possible combination of users like you would with message-based encryption. But whilst it's not  a lot of effort, it does require some effort on both ends before you can use it.

Whilst this isn't  a big deal between regular business partners it's not something you would realistically have in  place with every single person you might want to email. That's why most emails are actually using  opportunistic encryption.

The Encryption Gap

So most emails use opportunistic encryption. What's the big deal? Unless I'm communicating with someone on a really old platform, I'm good... right? Not necessarily.

Opportunistic encryption is fine to prevent random people from peeking at the message in transit but has a couple of fairly significant weaknesses. The first is that it's not guaranteed. An otherwise  modern system could fail to do the encryption due to a configuration issue (usually because an  encryption certificate expired and nobody noticed).

The other problem is that it provides no  protection against a man-in-the-middle attack. It only works if you manage to connect  to the correct receiving server and both ends behave themselves. If someone is  actively trying to intercept your messages they can easily circumvent this if they manage to  place themselves between you and the recipient. If they can trick you into connecting to their  server instead; they can either have their server say it doesn't do encryption and receive the  message in plain text, or they could even just provide any old encryption certificate and it  would still work. If they can't manage to get you connected to their server but they can disrupt the  initial plaintext connection between you and the recipient, they might be able to cut out the offer  of encryption and force the connection to plain text.

A man-in-the-middle attack could also happen  with enforced encryption using a dodgy certificate, but if you go to the effort of specifying that  a particular server needs to use encryption then you could also go to the effort of saying  that you're going to enforce a validity check on the certificate while you're at it. You don't  have that option with opportunistic encryption because it's just best efforts. If the server is  using encryption and has a publicly verifiable certificate, great. If not but it can do encryption  with any old certificate, that's fine too. If it can't do any sort of encryption, that's still  fine, we'll just send a message in plain text.

MTA-STS & Final Thoughts

So what's the fix? Well, that's what the MTA-STS standard sets out to do; or Mail Transfer Agent Strict Transport Security, to give it its full  title. MTA-STS is a way of publishing a public statement that your server supports proper,  verifiable encryption. If a sending server that supports MTA-STS sees your public declaration  on the internet they know that not only should they be able to encrypt their connection to you, they should also be able to publicly verify the identity of your server using its certificate. Where both sides support it, it basically has the effect of upgrading the connection to enforced TLS, with certificate identity verification, without the need for the sender's and recipient's IT departments to get in touch with each other first. If the sender doesn't receive an offer of encryption, or it does get an offer of encryption but using a wonky certificate, it will refuse to send the email.

MTA-STS is still in the early stages of adoption, but with Google already pushing it and Microsoft  jumping onboard it looks set to become the new standard over time. So let's bring this all  together. What actions should you be taking to make your emails more secure?

  • First, make sure  your email platform supports opportunistic TLS.
  • Second, make sure it's using a publicly signed  certificate that matches the name of your server.
  • Third, configure MTA-STS to make sure you have the  best chance of getting the most secure connection.
  • Fourth, if there are known business partners  where you want to guarantee encryption, consider enabling strictly enforced TLS with  mutual certificate authentication on both ends. The exact names used will vary system-to-system, but some  combination of what I've just said should show up. If you need to guarantee that nobody else can read  the emails, even if the recipient's mailbox gets stolen; then you might want to consider message-level encryption like S/MIME or PGP for those special cases.
  • Finally, you could also just use  something other than email. There are other ways to share information that don't have the same legacy  issues.

This will all give you the best chance of making sure your messages are transmitted in a  secure way, safe from prying eyes. What it won't do. though; is prevent someone spoofing your messages. That's a whole different set of problems.

Comments (0)

    No comments yet

You must be logged in to comment.

Sign In / Sign Up