Let’s Encrypt Comes Up With Solution for Bizarre Problem

The problem itself is fairly straightforward. Let’s Encrypt launched in 2016, and while it waited to have its root certificate approved and added to browsers and OSes, it reached an agreement with existing certificate authority IdenTrust to cross-sign it’s SSL certs. This meant that as long as IdenTrust’s widely deployed root certificate was on a device, then Let’s Encrypt certs would be accepted as valid by that device.

But that IdenTrust root certificate expires in September 2021, and Let’s Encrypt will transition to using its own widely deployed root certificate going forward.

Except on one operating system–Android.

Let’s Encrypt was added to Android’s certificate authority store in Android 7.1.1, released in December 2016. So devices using version 7.1.1. or newer will have no problems at all when the IdenTrust root certificate expires. Let’s Encrypt’s root cert is already included in the Android OS, and things will be fine.

The problem is that almost 34 percent of Android devices are running a version older than 7.1.1. That translates to about 845 million devices still running an OS that is more than four years old.

Let’s Encrypt found a workaround, but it’s crazy that 845 million Android devices being actively used have an OS that hasn’t been updated in four years, and that likely can’t receive updates even if their owners wanted to.

Ironically, one of the bug fixes rolled out in 7.1.1 was an update to Android’s CURL/LIBCURL libraries, which had bugs that could allow a malicious actor with a forged certificate to launch a remote code execution attack.

Hell, Let’s Encrypt’s workaround relies on the fact that Android ignores crucial security settings. Even though a root certificate like IdenTrust’s has an expiration date, Android ignores that expiration date. So IdenTrust has agreed to extend its cross-signing of Let’s Encrypt certs for three years.

IdenTrust has agreed to issue a 3-year cross-sign for our ISRG Root X1 from their DST Root CA X3. The new cross-sign will be somewhat novel because it extends beyond the expiration of DST Root CA X3. This solution works because Android intentionally does not enforce the expiration dates of certificates used as trust anchors. ISRG and IdenTrust reached out to our auditors and root programs to review this plan and ensure there weren’t any compliance concerns.

Handshake–A Decentralized Naming and Certificate Authority

Handshake is an attempt to create a decentralized naming and certificate authority.

Handshake is a decentralized, permissionless naming protocol where every peer is validating and in charge of managing the root DNS naming zone with the goal of creating an alternative to existing Certificate Authorities and naming systems. Names on the internet (top level domains, social networking handles, etc.) ultimately rely upon centralized actors with full control over a system which are relied upon to be honest, as they are vulnerable to hacking, censorship, and corruption. Handshake aims to experiment with new ways the internet can be more secure, resilient, and socially useful with a peer-to-peer system validated by the network’s participants.

Handshake is an experiment which seeks to explore those new ways in which the necessary tools to build a more decentralized internet. Services on the internet have become more centralized beginning in the 1990s, but do not fulfill the original decentralized vision of the internet. Email became Gmail, usenet became reddit, blog replies became facebook and Medium, pingbacks became twitter, squid became Cloudflare, even gnutella became The Pirate Bay. Centralization exists because there is a need to manage spam, griefing, and sockpuppet/sybil attacks. Previous decentralized systems largely stopped working due to spam. If it were more costly to grief on the internet using decentralized systems, the need for trusted centralized corporations to manage these risks decrease. Internet services and platforms may benefit from building on top of a decentralized system which is specifically designed for resilience against sybil attacks.

As we may redecentralize.

Let’s Encrypt Reaches 100 Million Certificates Milestone

Let’s Encrypt announced this week that they’d passed the 100 million certificates issued threshhold,

Let’s Encrypt has reached a milestone: we’ve now issued more than 100,000,000 certificates. This number reflects at least a few things:

First, it illustrates the strong demand for our services. We’d like to thank all of the sysadmins, web developers, and everyone else managing servers for prioritizing protecting your visitors with HTTPS.

Second, it illustrates our ability to scale. I’m incredibly proud of the work our engineering teams have done to make this volume of issuance possible. I’m also very grateful to our operational partners, including IdenTrust, Akamai, and Sumo Logic.

Third, it illustrates the power of automated certificate management. If getting and managing certificates from Let’s Encrypt always required manual steps there is simply no way we’d be able to serve as many sites as we do. We’d like to thank our community for creating a wide range of clients for automating certificate issuance and management.

The press release also notes that when Let’s Encrypt began issuing certificates, Firefox’s Telemetry report found that

. . . less than 40% of page loads on the Web used HTTPS . . . In the 19 months since we launched, encrypted page loads have gone up by 18%, to nearly 58%.

A very good trend.

Peter Eckersley’s Presentation on Let’s Encrypt at CCCamp15

Peter Eckersley gave an impressive presentation about the Let’s Encrypt initiative at CCCamp15.

Let’s Encrypt is mainly known for it’s plan to offer free SSL certificates, which is cool, but the most interesting part of Eckersley’s presentation starts about 25 minutes in where he discusses how the initiative plans to address issues surrounding vulnerabilities related to the Certificate Authority system itself.

The only thing I see personally that I wish Let’s Encrypt supported right out of the gate is Wildcard Certs, but Eckersley indicates in the Q&A session that they will be looking into things like Wildcard Certs after they’re certain the basic functionality of their CA is rock solid.