Let's Encrypt and a TLS monoculture

December 10, 2017

Make no mistake, Let's Encrypt is great and I love them. I probably wouldn't currently have TLS certificates on my personal websites without them (since the free options have mostly dried up), and we've switched over to them at work, primarily because of the automation. However, there's something that I worry about from time to time with Let's Encrypt, and that's how their success may create something of a TLS monoculture.

In general it's clear that Let's Encrypt accounts for a large and steadily growing number of TLS certificates out there in the wild. Some recent reports I could find suggest that it may now be the largest single CA, at 37% of observed certificates (eg nettrack.info). Let's Encrypt's plans for 2018 call for doubling their active certificates and unique domains, and if this comes to pass their dominance is only going to grow. Some of this, as with us, will come from Let's Encrypt displacing certificates from other CAs on existing HTTPS sites, but probably LE hopes for a lot of it to come from more and more sites adopting HTTPS (with LE certificates).

This increasing concentration of TLS certificates from a single source has two obvious effects. The first effect is that it makes Let's Encrypt itself an increasingly crucial piece of the overall HTTPS infrastructure. If Let's Encrypt ever has problems, it will affect a whole lot of sites, and if it ever has security issues, it seems very likely that browsers will be even less prepared than usual to do much about it. That Let's Encrypt certificates only last for 90 days also seems likely to magnify any operational issues or scaling problems, since it increases the certificate issuance rate required to support any given number of active certificates.

(As far as security goes, fortunately increasingly mandatory certificate transparency makes it harder for an attacker to hide security exploits against a CA.)

Beyond security issues, though, this implies that any Let's Encrypt policies on who can or can't get TLS certificates (and under what circumstances) may have significant and disproportionate impact. Let's Encrypt is currently fairly unrestricted there, as far as I know, but this may not be under their control under all circumstances; for example, legal judgements might force them to restrict or block issuance of certificates to some groups, network areas, or countries.

The second effect is that HTTPS TLS certificate practices are likely to increasingly become dominated and defined by whatever Let's Encrypt does (and doesn't). When LE issues the majority of the active certificates in the world, your code and systems had better accept their practices and their certificates. If LE certificates include some field, you'd better be able to handle it; if they don't, you're not going to be able to require it. Of course, this gives Let's Encrypt political influence over TLS standards and operational practices, and this means that persuading Let's Encrypt about something is valuable and thus likely to be something people pursue. None of this is surprising; it's always been the case that a dominant vendor creates a de facto standard.

(The effects of Let's Encrypt on client TLS code are fortunately limited because there are plenty of extremely important HTTPS websites that are very unlikely to switch over to Let's Encrypt certificates. Google (including Youtube), Microsoft, Facebook, Twitter, Amazon, Apple, etc, are all major web destinations and all of them are likely to keep using non-LE certificates.)

Written on 10 December 2017.
« You don't have to authorize a machine for Let's Encrypt from the machine
Some things about booting with UEFI that are different from MBR booting »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Dec 10 22:11:09 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.