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