“Encrypted” emails

It is Tuesday, and as I alluded to in my #WeblogPoMo capstone post, I will be posting Tuesdays and Fridays, and it is time! This one, to start off this new chapter correctly, is late, because I spent most of the day in London in the ExCel conference centre at day 1 of Infosecurity Europe. It was fun! I got to meet some of the people who worked the stand of the company I work for, got to chat with a bunch of vendors and other exhibitors, some of them recognised the company I work for, and it was generally a good time!

Got my usual swag, which consists of:

• 3 pairs of socks
• 1 t-shirt
• 1 tote bag
• 1 notebook
• 2 X for dummies, lite edition books
• a bunch of informational A4 flyers about their respective products / services
• bunch of stickers, 6 of which feature cats (all from the same vendor)
• small thermo pack capable of holding 6 cans of beers with 4 cans of energy drinks inside
• 2 pens

But enough about that, let’s talk about encrypted emails.

When you open your favourite email client, which is obviously Microsoft Outlook, and you compose an email, that’s the email I’m talking about. Cloudflare has a pretty good article on what it is, but some highlights:

• you need at least two servers: a sender, and a recipient server
• sender is called an MTA, or Mail Transfer Agent, recipient is an MX, or Mail eXchange server. The latter is why you have MX records in your DNS
• then you have the email itself, which consists of three parts:
  • SMTP (simple mail transfer protocol) envelope, this is the sender’s email, and recipient’s email address(es)
  • header: all the “unseen” parts of an email. Ideally the sender/recipient data matches what was in the SMTP envelope, but it doesn’t need to be. Your DMARC, SPF, Subject, and other random things go here
  • body: the thing you wrote to the recipient, including any and all attachments
• when you click send, your server finds the recipient’s server based on the address
• when found, it chucks the email over to the other server
• other server will give the recipient a notification that they have a message they should read

Of these the important part for us is the email message itself with the two parts: header and body. The SMTP envelope gets discarded after the email is transferred to the receipient mail exchange servers.

So here’s a small email I wrote to myself:

And here’s that same email’s source. That link takes you to a raw gist on GitHub, because Ghost’s collapsible toggle content thingy doesn’t allow code snippets, and pasting the entire source code here in plain sight would be a jarring experience. What you’ll notice is that it’s about 99% headers and 1% body.

This is the body:

Content-Type: multipart/alternative; boundary="00000000000017f194061a166e97"

--00000000000017f194061a166e97
Content-Type: text/plain; charset="UTF-8"

boop

--00000000000017f194061a166e97
Content-Type: text/html; charset="UTF-8"

<div dir="ltr">boop<br></div>

--00000000000017f194061a166e97--

I’m going to stop explaining what an email is, because I found a really in–depth post about it by Matt Bearman titled Anatomy of an email. Go read that instead. Shout-out to a fellow Ghost user!

So the point of all of it is that when your sender server sends the entire raw message to the recipient server, all of that is plain text. Unencrypted. If someone were to copy the traffic between the two servers, they will be able to read the email, attachments and all, which is why you don’t send your health data, passport scans, etc over email, right? Right?

We know that out of the box email is not encrypted at all. It’s plain text. This is roughly what happens:

Ideally this is what an encrypted email should look like:

This is unviable for a bunch of reasons.

1. you need to deal with distributing your encryption keys
2. you need to have a pair of keys for each recipient
3. you need to have more for each combination of recipients
4. that’s quickly becoming unfeasible
5. plus each recipient needs to have a piece of software installed in their email client or browser that recognises an encrypted email and uses the correct key to decrypt the message

Obviously symmetric encryption isn’t going to work. Therefore the only other way to do this is asymmetric encryption! Hah, putting my cybersecurity certification to good use!

Asymmetric encryption works by encrypting something using one key, and decrypting it with another. In practice this will most certainly mean public–private keys. Encrypt the message using the recipient’s public key, which you know, obviously, and they can decrypt it with their private key, which only they know. This has the added benefit that the number of keys you need to maintin drastically goes down, but that’s about it. Here are the challenges:

1. each recipient must have a public key created, in use, maintained, and available for others to acquire
2. both sender and recipient needs to use an email client that supports public key cryptography
3. what happens to emails with a lot of cc: and bcc: fields? I assume for each message sent to each recipient, the message would be encrypted using their specific public key
4. the moment the recipient doesn’t have a public–private key pair, they either can’t read the email, or the email gets sent plain text, in which case the whole exercise is moot

Outside of hardcore old timers who still use OpenPGP to deal with email encryption, this introduces so much friction to everyone who has an email address that it might just not exist. I can’t imagine primary school teachers even know what a public key is. Or my doctor. Or anyone working in government. It’s not their job to know about it.

Looping back to the beginning of this article now. I talked to a bunch of vendors who offer email encryption. It was fascinating. They don’t actually encrypt the emails. Here’s what they do instead:

The steps:

1. you pay for their solution, and get a plugin for your email client or browser with an API key
2. you write your message as normal, hit send as normal
3. the plugin hijacks the message, takes the content out of the email, copies it up to their web portal, encrypts it, generates a signed link to it, and assigns it to a user identified by the recipient’s email address
4. plugin takes that link from the web portal, and replaces the entire email body with something like “Hi, you have a new secure message, click this link to view it!”
5. your email server sends out that message
6. recipient gets the email, clicks on the link, signs up / signs in to the web portal, and now they can read the message there
7. they usually have an option to respond to it inside the portal too

They are not encrypting the email. They move the conversation to a web based messaging system where the only purpose an actual email serves is telling people that they moved the conversation to a web based portal.

If Twitter was still a thing, I would create an “email encryption app” that would move all email to Twitter DMs. Maybe instagram. Or mastodon. Maybe activity pub. Who knows, the possibilities are endless!

If you liked this post, consider subscribing! Or letting me know what you thought of the post some other way. Otherwise, see you on Friday!