37

According to NetTrack, Let's Encrypt is now used on more than 50% of domains (51.21% as of April 2018).

I know Let's Encrypt helped a lot of people to get free certificates for their websites, so I think its existence was a very good thing for the web.

But does the fact that a certificate authority is used by the majority of users cause security risks?

Note: this question is CA-agnostic, even if Let's Encrypt is the main CA today.

Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65

2 Answers2

38

TL;DR: It does not matter much.

The only security "risk" here really is the CA being "Too big to fail", where the browsers cannot distrust the CA quickly. But this is happening to all big CAs, not just the biggest one.

Other than that, the only problem may be the CA being a more tempting target, though all CAs are already very tempting. Having all the eggs in one basket has its advantages and its disadvantages in this situation. Advantage is, that you need to protect just one basket, disadvantage is that if that basket breaks, the impact is somewhat bigger (assuming technologies like CAA and HPKP are used, otherwise it does not matter how big the CA is).

Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
Peter Harmann
  • 7,728
  • 5
  • 20
  • 28
  • 13
    Also Let's Encrypt certificates usually only have a short period where they are valid (3 Months). Which would make a rollover to a new uncompromised CA easier. – Johannes Kuhn Apr 24 '18 at 16:58
  • 4
    @JohannesKuhn not really. There was similar problem with Symantec, where because of automation of certificates renewal (which Let's Encrypt pushes hard) and possibly HPKP, even disallowing issuance of new certificates was a problem, more here: https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/ Also this question was supposed to be CA-agnostic. – Peter Harmann Apr 24 '18 at 17:02
  • 1
    @PeterHarmann I see no mention of automation or HPKP in the blog. I use HPKP with automation and with leaf hashes only, so CA failure would still allow me to *immediately* tun to a different CA and submitting a certreq for a privkey whose hash is already listed in my HPKP header. (Well, hpkp seems to be being phased out since then anyway) – Hagen von Eitzen Apr 25 '18 at 03:17
  • @HagenvonEitzen Yes, if you use HPKP with leaf certs and rotate your keys properly, that is the preferable way, but because of how tricky HPKP is, many sites will probably just pin the CA root (and hopefully a backup key). As for automation, because different CAs will use different SW and APIs, it may not be as easy to reconfigure, especially with short period certificates. The blog explains the phases taken to minimize the impact. It does make my point of browsers not wanting to do it at once nicely. If you want to see all the reasoning, there are links to Google groups, where it was argued. – Peter Harmann Apr 25 '18 at 08:58
  • 2
    @PeterHarmann Regarding the automation, Let's Encrypt is pushing for open standards for precisely that kind of reason: any new CA could implement the ACME protocol and tools *should* just be able to switch straight over. That kind of thing's never as simple in practice as it should be, but it's a lot better than being locked into a set of proprietary tools that need replacing wholesale. – IMSoP Apr 25 '18 at 13:40
  • @IMSoP Well that is nice in theory, but until other CAs actually use them, it is of no help. – Peter Harmann Apr 25 '18 at 13:42
  • @PeterHarmann Indeed, I admitted it wouldn't be simple in practice; but at least other CAs *can* use them; that's not true of someone wanting to take on Symantec's clients - they'd probably have to reverse engineer a proprietary protocol, and risk being sued for copyright infringement if they disassembled the tools. – IMSoP Apr 25 '18 at 14:00
  • @IMSoP yes, but again, this question is supposed to be CA-agnostic. The author is not asking about Let's Encrypt but any CA in general getting too big. – Peter Harmann Apr 25 '18 at 14:01
  • @PeterHarmann Even if you were talking about a hypothetical CA, you could describe factors that would make it more or less problematic to migrate, and they would include how easy it would be for another CA to take over automated provisioning. "CA agnostic" doesn't mean "not allowed to discuss any possible properties of the hypothetical CA", or else the whole question is meaningless. – IMSoP Apr 25 '18 at 14:10
  • 1
    @IMSoP but you are not taking hypothetical problems. You are talking hypothetical solutions. If we don't know what CA we are talking about, we should assume the worst, namely that it runs everything on proprietary SW and actively hinders the transition out of spite. – Peter Harmann Apr 25 '18 at 14:15
  • 1
    @PeterHarmann I disagree, I think it's perfectly valid to discuss a number of different scenarios, not just active resistance, and have posted an answer doing so. – IMSoP Apr 25 '18 at 14:33
2

To break this discussion out of comments on the other answer: one issue with a single CA dominating is that if there is a problem requiring it to be replaced (e.g. browsers stop trusting it, or it goes bust), there needs to be somewhere for everyone to migrate to. This is true of any CA, but if customers are spread around many different providers, there is a smaller number needing to migrate, and switching providers will be a more common occurrence as people shop around for the best deal.

In the extreme case, a collapsing monopoly would require a completely new CA to be set up, or at least a small one to scale up very quickly. If existing certificates could be trusted, but none issued after a certain date, the timescale would depend on how long certificates were issued for.

If the CA were issuing short certificates and relying on automatic renewal systems, then either users would need to replace their automation infrastructure, or the new CA would need to provide a compatible service. This would be somewhat easier if the service provided by the old CA was based on open standards or open-source code (as happens to be the case with Let's Encrypt), since the new CA would not need to reverse-engineer it to take it over; similarly, there might be scenarios where the old CA was willing to co-operate in the transition. There would still be effort involved if the new CA was not already implementing the same protocol, of course.

IMSoP
  • 3,780
  • 1
  • 15
  • 19