It’s this time of year again, sending emails from Thunderbird fails with an error message:
The certificates I use to sign my emails have expired. So I once again need to go through the process of getting replacements. Or I could just give up on email signing and encryption. Right now, I am leaning towards the latter.
Why did I do it in the first place?
A while back, I used to communicate a lot with users of my popular open source project. So it made sense to sign emails and let people verify — it’s really me writing. It also gave people a way to encrypt their communication with me.
The decision in favor of S/MIME rather than PGP wasn’t because of any technical advantage. The support for S/MIME is simply built into many email clients by default, so the chances that the other side would be able to recognize the signature were higher.
How did this work out?
In reality, I had a number of confused users asking about that “attachment” I sent them. What were they supposed to do with this smime.p7s file?
Over the years, I received mails from more than 7000 email addresses. Only 72 signed their emails with S/MIME, 52 used PGP to sign. I only exchanged encrypted mails with one person.
What’s the point of email signing?
The trouble is, signing mails is barely worth it. If somebody receives an unsigned mail, they won’t go out of their way to verify the sender. Most likely, they won’t even notice, because humans are notoriously bad at recognizing the absence of something. But even if they do, unsigned is what mails usually look like.
Add to this that the majority of mail users are using webmail now. So their email clients have no support for either S/MIME or PGP. Nor is it realistic to add this support without introducing a trusted component such as a browser extension. But with people who didn’t want to install a dedicated email client, how likely are they to install this browser extension even if a trustworthy solution existed?
Expecting end users to take care of sender verification just isn’t realistic. Instead, approaches like SPF or DKIM emerged. While these aren’t perfect and expect you to trust your mail provider, fake sender addresses are largely a solved issue now.
Wouldn’t end-to-end encryption be great?
Now we know of course about state-level actors spying on the internet traffic, at least since 2013 there is no denying. So there has been tremendous success in deprecating unencrypted HTTP traffic. Shouldn’t the same be done for emails?
Sure, but I just don’t see it happen by means of individual certificates. Even the tech crowd is struggling when it comes to mobile email usage. As to the rest of the world, good luck explaining them why they need to jump through so many hoops, starting with why webmail is a bad choice. In fact, we considered rolling out email encryption throughout a single company and had to give up. The setup was simply too complicated and limited the possible use cases too much.
So encrypting email traffic is now done by enabling SSL in all those mail relays. Not really end-to-end encryption, with the mail text visible on each of those relays. Not entirely safe either, as long as the unencrypted fallback still exists — an attacker listening in the middle can always force the mail servers to fall back to an unencrypted connection. But at least passive eavesdroppers will be dealt with.
But what if S/MIME or PGP adoption increases to 90% of the population?
Good luck with that. As much as I would love to live in this perfect world, I just don’t see it happen. It’s all a symptom of the fact that security is bolted on top of email. I’m afraid, if we really want end-to-end encryption we’ll need an entirely different protocol. Most importantly, secure transmissions should be the default rather than an individual choice. And then we’ll only have to validate the approach and make sure it’s not a complete failure.
Comments
I have to agree. A fair number of people I dealt with used signing in the past, usually via gnupg… some still do, but I think most have given up. And I only know one friend who’d routinely encrypt email to other friends…
And yeah, the rise of cloud-based interfaces like GMail have made it a lot harder to use… no native clients to integrate with signing/encryption tools, or if there is a native client, it won’t support that kind of functionality. Plus, encryption tends not to co-exist very well with the ability to search your email history, and like most people, being able to use my email is more of a concern than the prospect of someone being able to read it (since I avoid sending anything sensitive that way).
“approaches like SPF or DKIM […] expect you to trust your mail provider”
Are there any reason that DKIM signing couldn’t be build into Thunderbird?
Sure, because then you are back in the same mess. You have to distribute private keys to the clients, you have end-users managing keys etc. Oh, and how do you ensure that the key is valid? With DKIM applied on domain level you get the public key from DNS. And never mind those 80% email users relying on webmail.
Keep an eye on what the p≡p foundation is doing.
What you mention has been recognized, and there is work at all levels (software & UX & IETF standardization) being done. Consider supporting the effort!
Looking forward to the day this gets incorporated at least in Thunderbird. Enigmail is a very geeky solution, nothing like “secure by default” that Thunderbird should be out of the box.
Yes, I agree that there is little chance of email encryption to gain any meaningful momentum. If at all it would ironically come from B2B, where email is still a key communication means. But it is overall unlikely exactly due to the bad implementation and complexity.
And that has always been the bane of email encryption IMHO. Technically there is no problem, since Whatsapp is encrypting nowadays and has shown us how to do things so that they get easily adopted – I mean even when WhatsApp was technically crap in the beginning, they just did everything right when it came to ease of use.
Practical usability is the most important factor. Security comes second. This has never been understood by the guys who developed PGP, Gnupg and S-Mime. Super-safe and not useable is useless. And becomes obsolete later.
The main issue is always determining the correct public key of your contact. I don’t think Whatsapp really solves it.
I agree that for personal use, S/MIME and PGP is overly complicated and really un-necessary. But for B2B it still has lots of use and is continuing to grow (especially digital signatures). You should check out GlobalCerts solution. It is gateway-level, and all user certificates are managed centrally by admins. It is a gateway-level signature/encryption solution, which necessitates a certain amount of trust within your email infrastructure and mail clients/devices, but eliminates all the problems of signing/encrypting direct from each mail client.
Also, we have spearheaded the idea of using DNS to distribute/publish S/MIME public keys of users. Optimally this would be done onto the public DNS via SMIMEA records, but for now we use a proprietary closed system called SecureTier. This allows all our customers to communicate securely via S/MIME with all other customers with no need to exchange a signed email first.
That's actually part of the issue. We looked into deploying email encryption company-wide, so that at least internal communication would be encrypted by default. And we found no feasible way to achieve that. The only possibility would be a mail gateway like yours. That would be pointless for any communication within the company, not being real end-to-end encryption. And maybe I have been communicating with the wrong companies but I didn't see a single signed email come in - so other companies don't have a signing/encryption setup, and the likelihood of a mail gateway on our end doing something useful would be close to zero.