EFFecting Digital Freedom

by Jacob Hoffman-Andrews

Let's Encrypt: Scaling HTTPS and TLS to the Whole Internet

If you were to design the Web from scratch today, each URL would start with: https://

Or rather, it wouldn't because you would build in encryption from the start, and it would be on by default.  There would be no need to single out the more secure protocol as special.

We're stuck with the Internet we've got, however.  Using HTTPS in place is simple, cheap, and effective.  It's one of a tiny handful of encryption protocols that nearly everyone on the Internet uses every day, and most people are hardly even aware of it.  But a majority of sites don't even offer HTTPS, let alone use it by default.

At the same time, the increasing affordability of mass interception and storage technology means that every action taken on a plaintext HTTP website is subject to spying.  Worse, we've seen that browsers' default HTTP usage puts users at risk of hijacking to insert malware (QUANTUM), DDoS JavaScript (Great Cannon), tracking headers (X-UIDH), or advertisements (AT&T hotspots).  Unencrypted should mean untrusted.  But with the huge number of unencrypted sites out there, browsers can't start blocking HTTP content by default.

We are making progress, though.  After Eric Butler's Firesheep extension viscerally demonstrated the ease of hijacking web sessions, large websites like Twitter and Facebook began implementing HTTPS by default.  Google was already using HTTPS for Gmail, but has since expanded their efforts to include most of their sites.

Major sites are able to dedicate time and resources to implementing HTTPS.  But if we want to transition to an Internet where everything is encrypted, we want to make sure that transition doesn't increase the burden on individuals who want to speak on the Internet.  It should always be possible to set up a server of your own, to express your own views to anyone who wants to listen, no matter how unpopular they are.

For a long time, HTTPS was inaccessible to most individuals.  Purchasing the required certificate used to cost hundreds of dollars.  With time, certificate prices have dropped dramatically, and now you can get a free certificate from StartSSL or WoSign.  Still, though the monetary barriers are lower, the barriers of time and technical ability remain high.  Experienced web administrators commonly take one to three hours to issue a single certificate.  Less experienced people may fail completely.  And the administrator must remember to renew each certificate every year, or their site will break: a surprisingly common occurrence, even for high-traffic web sites.

To secure the Internet, we need to make HTTPS ubiquitous.  To make HTTPS ubiquitous, we need to make sure everyone can implement it, from the largest commercial site to the smallest forum, regardless of money or technical experience.  This is why EFF and Mozilla, along with major sponsors Akamai, Cisco, IdenTrust, and Automattic, started Let's Encrypt.

Let's Encrypt will be a free, automated Certificate Authority (CA), run by an independent non-profit, the Internet Security Research Group (ISRG).  It will provide Domain-Validated (DV) certificates, which vouch that the person who controls a given hostname uses a certain public key for that hostname (the other major type of certificate, Extended-Validation (EV), additionally vouches for the location and legal name of the entity behind a certificate, typically an organization.  Since EV is not amenable to automation, it's not in scope for Let's Encrypt.).

There are three major components to the plan: a protocol, a certificate authority, and a client.  Automatic Certificate Management Environment (ACME) is a new protocol designed to cover the entire certificate life cycle, including domain name validation, issuance, renewal, and revocation.  ACME meets the needs of Let's Encrypt, but our hope is that it will be more broadly adopted and become an Internet standard.  To that end, there is an ACME working group at the Internet Engineering Task Force (IETF).

ACME is based on the recently standardized JSON Web Signature standard.  After enrolling with the server, a client authenticates each of its requests by signing it with a JSON Web Key.  To receive a certificate, the client must first prove that it controls each relevant hostname.  The ACME protocol provides a challenge-response system that can be adapted to the policy of the CAs deploying it.  For instance, a CA could request that the client provision a certain file at a well-known path on a web server that answers for that hostname, or require a code sent by email to an administrative address.  Once the client has proved control of the hostname, it can submit a certificate request and receive an automated response.

To prove the usefulness of the ACME protocol, and (more importantly) to provide easy-to-use certificates for the Internet, ISRG is also creating a free CA.  Let's Encrypt will have its own root certificate, which will be submitted to the various trust root programs for inclusion in browsers.  However, to make sure the certificates it issues are immediately usable by the widest range of browsers, ISRG will also be getting its intermediate cross-signed by IdenTrust's root certificate.  The Let's Encrypt certificate authority will operate using Boulder, a from-scratch implementation of the server-side of the ACME protocol in Go.

The third and final component is the Let's Encrypt client.

Besides speaking the ACME protocol, the Let's Encrypt client will perform two other important tasks: auto-configuring the new certificate in a local web server, and renewing the certificate periodically.  Automated renewal is particularly important because expired certificates are one of the biggest causes of certificate warnings, and they are most commonly due to simple human error.  Not only do expired certificates cause site downtime, they also train users to click through browser warnings.  Auto-configuration is important because there are many common and time-consuming pitfalls in setting up HTTPS, such as forgetting to install an intermediate cert, or leaving the default, often insecure set of cipher suites.

Not everyone will want to use Let's Encrypt's auto-configurator, though, and it will be possible to issue a certificate without installing it.  And of course, ACME is an open protocol so anyone can write their own client.  There are at least three third-party ACME clients already in the works.

Let's Encrypt is planning to launch to the general public on November 16, 2015.  The code is available on GitHub, and all input is welcome, especially security analysis.

If you find a vulnerability in Boulder or the Let's Encrypt client, please mail security@letsencrypt.org.

For general questions, join us in the Let's Encrypt community support forums at community.letsencrypt.org.