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 video I'm going to help you stop them.
Welcome back to The Pro Tech Show where I talk about tech, Tips and advice for IT pros and
decision makers. 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. Do people still do that? I might be showing my age there!
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. OK, 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.
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. Luckily
for you, it's also a set of problems I've already made a video about solving, so I'll pop it up here
for you and I'll try to remember to drop it in the comments as well. If you found this helpful
then give it a like and don't forget to subscribe to the channel to see future videos like this one.
That's me done for now. Go watch that other video. Thanks for watching, guys. See you next time!