You’ve probably heard of Let’s Encrypt, not least because we’ve written about it many times on Naked Security.
Let’s Encrypt is a non-profit project that’s supported and sponsored by a wide range of high-profile internet companies and other non-profits.
The project has a fairly straightforward goal: to help websites make the switch to secure HTTP, better known as HTTPS, the protocol that puts the padlock in your browser.
HTTPS, simply put, is regular HTTP transmitted by means of an underlying network protocol known as Transport Layer Security, commonly known by its abbreviation TLS.
TLS is often still referred to, imprecisely, by its earlier name of SSL, which stood for Secure Sockets Layer. SSL is a backwards-compatible precursor of TLS that is no longer considered secure enough for use. You shouldn’t initiate or accept SSL connections any more – they give a false sense of security to both sender and recipient.
If you run a website that doesn’t ask users to login and doesn’t have any forms on which visitors might fill in personal data, it’s easy to slip into the habit of saying “encryption doesn’t matter.”
The anti-HTTPS excuses typically look like this: I’ve got nothing to hide, the pages I’ve serving up are meant to be public anyway, I never ask for or send out personally identifiable information, and there’s nothing on the site that could be considered incriminating to anyone reading it.
More than confidentiality
But the encryption provided by HTTPS isn’t only about confidentiality – it’s also about integrity and authenticity.
You owe it to your visitors to make them confident that they’re really visiting your site, not an imposter’s clone that’s riddled with scams and bogus content, and that they’re really getting your official files for download, not some modified and malware-tainted alternatives.
Nevertheless, even with the excuses for not using HTTPS swept aside, two primary reasons stood in its way until Let’s Encrypt came along: “going encrypted” took time and it cost money.
You need a TLS security certificate, and a trusted third-party needs to sign it – a process that used to be much more easily said than done.
Let’s Encrypt not only made the process simpler but also waived the fees for issuing signed security certificates, resulting in a huge decrease in the number of holdout websites that refuse to bother with HTTPS at all.
In fact, HTTPS is now prevalent enough that the Chrome browser is about to start shouting at you about any sites that aren’t encrypted, making HTTP into something to avoid altogether.
But what about email?
So much for the web – what about email encryption?
Who’s eavesdropping on your messages?
The good news is that if you use one of the major webmail services, and send email to another major webmail user, your emails are almost certainly cryptographically safe in transit.
The servers of webmail services like Gmail, Outlook.com and Yahoo! all use encryption when talking to each other, as well as when they talk to many other mainstream mail servers out there.
But plenty of non-webmail servers still aren’t bothering with server-to-server mail encryption, or are encrypting in a sub-standard way.
So the Electronic Frontier Foundation (EFF), one of the groups behind the Let’s Encrypt project, has announced a related effort called STARTTLS Everywhere for the world’s email ecosystem.
STARTTLS comes from the command used in the SMTP email protocol to switch into encrypted mode, and the STARTTLS Everywhere project aims to get everyone not only to use
STARTTLS, but also to use it properly.
EFF identified several problems:
- No support for STARTTLS at all. It’s easy enough not to bother with email encryption – it saves the hassle of acquiring a security certificate in the first place, and many corporate mail servers will still accept your messages anyway, even if they ask you to STARTTLS but you refuse.
- Insecure TLS certificates. Some mail server administrators have gone to the trouble of creating security certificates, but not of getting them vouched for by a recognised certificate authority such as Let’s Encrypt. These so-called self-signed certificates are perfectly legal, and super-easy to create, but they have a significant weakness: anyone can create a self-signed certificate in anyone else’s name. So, self-signed certificates miss out on one of the most important benefits of STARTTLS in email, namely verifying that you’re delivering your email to the right server in the first place.
- No downgrade protection. Unlike HTTPS connections from your browser, which start out using TLS and then talk HTTP over the secure-from-the-outset channel, email connections start out unencrypted and “upgrade” themselves to TLS later on after the
STARTTLScommand is used. An eavesdropper who can alter the unencrypted part of a mail connection can therefore strip out the
STARTTLScommands, sneakily turning a connection that was supposed to be encrypted into one that can be snooped on throughout.
EFF plans to solve problems 1 and 2 by extending the Let’s Encrypt system so that email administrators can quickly and easily add TLS support for free.
So the TL;DR version so far is simple: “STARTTLS Everywhere is just Let’s Encrypt for email sysadmins.”
A trickier problem
But problem 3 above is trickier to solve, at least in the short term.
In theory, if the vast majority of email administrators simply refused to send or to accept unencrypted mail connections at all, then the small minority of crypto-deniers remaining would have no choice but to join the encryption club and start doing things properly.
But there are still sufficiently many non-encrypting email servers out there that we still need to support the old-and-insecure ways for convenience.
In practice, therefore, mail servers will be forced to accept unencrypted connections from time to time.
That means they need a reliable way to differentiate between a server that wanted to use encryption but was tricked by an eavesdropper into not doing so, and a server that didn’t care or couldn’t do encryption.
(It’s no use asking an email server if it wants to do secure encryption unless you already have an encrypted channel to validate the answer.)
One posible solution is a draft internet standard called MTA-STS, jointly proposed by experts from Microsoft, Google, Yahoo! and Comcast.
Simply put, MTA-STS allows a mail server to use an HTTPS connection – because secure HTTP is something we already know how to do well – to declare its preference for using email encryption, and thereby to prevent a downgrade attack.
EFF is also helping out by hosting its own database called the STARTTLS Policy List, hosted on its own secure servers, that keeps track of email systems that meet various minimum standards for SMTP encryption.
What to do?
If you run your own mail server, or outsource your mail server to someone else, please take the time to study the EFF’s STARTTLS Everywhere technical document – it’s called a “deep dive” but it’s nevertheless a fairly short read.
We urge you to start doing server-to-server email encryption if you aren’t already, and we encourage you not to cut corners with self-signed certificates: after all, a job worth doing is worth doing well.
As we like to say: Dance like no one’s watching/Encrypt like everyone is.
9 comments on ““Safer hops for email” – EFF’s plan to cut down on email snooping”
“You owe it to your visitors to make them confident that they’re really visiting your site, not an imposter’s clone”
Nitpicking time: that’s not really what HTTPS is about. An imposter’s site could just as easily have an SSL certificate – especially now they’re free. If you’ve landed on an imposter’s domain, the presence of an SSL certificate doesn’t tell you anything, unless you carefully examine the properties of the certificate. And we know how many people do that on a regular basis!
HTTPS is more about ensuring that the content sent from the site hasn’t been tampered with in-transit, and that nobody monitoring the network between the client and the server can read the content of the request or response.
I get your point, but I’m going to stick with my wording.
You *do* owe it you to visitors to make them confident that they’re seeing your content, and HTTPS *does* help you to do that. Granted, just seeing the padlock is insufficient on its own, but at least HTTPS makes it possible to vouch for yourself, and to get a certificate authority to vouch for you in turn. In other words, if you don’t have HTTPS, you are letting your visitors down in respect of all three security aspects: confidentiality, integrity and authenticity.
In other words, I think I am saying that while you are right, I am not wrong :-)
Note to self: an article on “how to check TLS certificates in various browsers” might be a handy thing indeed. (Safari on iOS, for instance, tells you who owns the certificate – handy, but in the case of companies owned by other companies, not always terribly useful – but drilling in further than that is somewhere between hard and impossible.)
The vast majority of mail servers don’t check the authenticity of certificates when they move to TLS. As far as they’re concerned they’re just chatting encrypted. WHO they’re chatting encrypted to is another matter and they’re equally as susceptable to MITM attacks as unencrypted connections.
That said: If you’re facing a MITM attack at network level like that, you’re facing a determined adversary with significant budget who probably has legal leverage over your provider.
Good point. I probably ought to have added that as a separate item in the 3-point list… but I figured that making the list longer would make it more confusing.
In the end I figured that the issue of “uncheckable” self-signed certificates was a bigger issue – as long as there are enough of those floating around, servers are going to be slack about checking anyway.
“The word STARTTLS comes from the command used in the *STMP* email protocol to switch into encrypted mode, and the STARTTLS”… I believe you meant SMTP.
That logo could do with some work … why associate email security with hunting kangaroos?
I think there’s a double metaphor. Firstly, kangaroos travel in hops, like emails do in the SMTP delivery process. Secondly, if you encrypt the delivered data then it’s as though it is safely carried in the roo’s pouch (symbolised by the position of the @ sign in the logo).
Thus “safer hops for email”.
At first I couldn’t see how the logo might symbolise hunting any more than the apple-with-a-bite-missing logo on my Mac symbolises deforestation… but maybe you are reading the green circle over the @ sign as a symbolic gunsight? Perhaps you might want to suggest to EFF that they could get rid of it, or make it square?
Has there ever been an IPA drinker who sickened from unsafe hops?