Let's Encrypt - and Fix HTTPS While We're At It

A few weeks ago I wrote about the need for encryption - and the growing attacks against it by surveillance agencies worried about its efficacity. But how exactly can we implement that?


A few weeks ago I wrote about the need for encryption - and the growing attacks against it by surveillance agencies worried about its efficacity. But how exactly can we implement that?

One way is to adopt it at a personal level. That means using things likes PGP with Thunderbird, say. There are also a range of new email services that are aiming to offer easy-to-use encrypted email - something that cannot, alas, be claimed for the PGP+Thunderbird combo.

But another important way of hardening communications against snooping is on the server side: currently, it is mostly the "big" Web sites that offer HTTPS connections which make surveillance of traffic much harder (but by no means impossible, of course.) One reason why it tends to be the larger sites that adopt this is that adding encryption is fiddly and costs money - two things that smaller sites don't really want to deal with. That's why the Let's Encrypt project, announced a few weeks ago, is so significant:

The anchor for any TLS-protected communication is a public-key certificate which demonstrates that the server you’re actually talking to is the server you intended to talk to. For many server operators, getting even a basic server certificate is just too much of a hassle. The application process can be confusing. It usually costs money. It’s tricky to install correctly. It’s a pain to update.

Let’s Encrypt is a new free certificate authority, built on a foundation of cooperation and openness, that lets everyone be up and running with basic server certificates for their domains through a simple one-click process.

Mozilla Corporation, Cisco Systems, Inc., Akamai Technologies, Electronic Frontier Foundation, IdenTrust, Inc., and researchers at the University of Michigan are working through the Internet Security Research Group (“ISRG”), a California public benefit corporation, to deliver this much-needed infrastructure in Q2 2015.

As you can see, that comes with some pretty important organisations behind it, not least Mozilla and the EFF. And its core principles seem pretty solid:

Free: Anyone who owns a domain can get a certificate validated for that domain at zero cost.

Automatic: The entire enrollment process for certificates occurs painlessly during the server’s native installation or configuration process, while renewal occurs automatically in the background.

Secure: Let’s Encrypt will serve as a platform for implementing modern security techniques and best practices.

Transparent: All records of certificate issuance and revocation will be available to anyone who wishes to inspect them.

Open: The automated issuance and renewal protocol will be an open standard and as much of the software as possible will be open source.

Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the entire community, beyond the control of any one organization.

What's not to like? Well, actually, there is a problem, but it's not really Let's Encrypt's fault. Here's the issue, explained by the EFF's Technology Projects Director, Peter Eckersley:

Anyone who looks at the CA infrastructure is going to think, "oh, there are expensive high security CAs [certificate authorities issuing certificates], and weaker low security CAs, and hundreds of others run by various corporations and governments, I'd better pick one I can trust". But it turns out not to matter which one *you* pick, because our web browsers have been designed to trust hundreds of them. So even if you buy from the one with the best combination of security and jurisdictional robustness, a would-be man-in-the-middle attacker will pick a weak one to use against you.

In other words, the entire HTTPS system is based on a false premise: that you can actually trust the certificates that are used to authenticate secure sites. That's a pretty big failing. Eckersley explains how Let's Encrypt hopes to tackle this flaw:

Let's Encrypt's first mission will be to solve the grand problem of HTTPS, which is that hundreds of millions of sites don't use it at all. But it will also be engineered to begin addressing the structural flaws in the whole CA marketplace. For sites that it want it, we'll assist in using mechanisms like pinning to protect against the hundreds of other CAs that the site isn't using (pinning lets a site declare that only a small and specified number of CAs can sign certs for it).

That is, Let's Encrypt's first task is to get as many Web sites as possible using HTTPS, however flawed it may be. The second problem - rather harder - is fixing HTTPS. As mentioned above, the idea of "pinning" will help. Here's an explanation of the technique from Mozilla:

Public Key Pinning is a mechanism for sites to specify which certificate authorities have issued valid certs for that site, and for user-agents to reject TLS connections to those sites if the certificate is not issued by a known-good CA. Public key pinning prevents man-in-the-middle attacks due to rogue CAs not on the site's list.

However, clearly more than this is needed, and one approach is being explored by Google, with its Certificate Transparency project:

Google's Certificate Transparency project fixes several structural flaws in the SSL certificate system, which is the main cryptographic system that underlies all HTTPS connections. These flaws weaken the reliability and effectiveness of encrypted Internet connections and can compromise critical TLS/SSL mechanisms, including domain validation, end-to-end encryption, and the chains of trust set up by certificate authorities. If left unchecked, these flaws can facilitate a wide range of security attacks, such as website spoofing, server impersonation, and man-in-the-middle attacks.

Certificate Transparency helps eliminate these flaws by providing an open framework for monitoring and auditing SSL certificates in nearly real time. Specifically, Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.

Because it is an open and public framework, anyone can build or access the basic components that drive Certificate Transparency. This is particularly beneficial to Internet security stakeholders, such as domain owners, certificate authorities, and browser manufacturers, who have a vested interest in maintaining the health and integrity of the SSL certificate system.

There's already an IETF working group for this, aiming to create a standard RFC for Certificate Transparency. The renewed interest in fixing the long-standing problems with HTTPS is a beneficial side-effect of Edward Snowden's revelations about massive surveillance by the NSA and GCHQ amongs others. It's a pity it wasn't done before, in which case many of the more outrageous attacks on people's privacy by spy agencies around the world might have been avoided. Better late than never...

Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+