15

Let's Encrypt is based in the United States and subject to the laws of the United States, including National Security Letters. What are the implications for foreign sites that use Let's Encrypt?

Here's what I have come up with thus far:

  1. Let's Encrypt could be forced to revoke a certificate
  2. Let's Encrypt could be forced to issue a counterfeit certificate
  3. Let's Encrypt could be forced to keep any activities secret

Furthermore, Let's Encrypt is controlled by the Internet Security Research Group which includes members whose companies are part of the US PRISM program (Google, Facebook, etc).

Martin Schröder
  • 259
  • 1
  • 2
  • 16
RealDrGordonFreeman
  • 347
  • 2
  • 12

2 Answers2

12

Good questions all. I can't speak too much to other things they could do, but here's some comment on the ones your brought up:

  1. Yes, they could revoke a certificate. But while this could cause some availability issues for your users, it wouldn't compromise confidentiality or integrity.
  2. Let's Encrypt could issue a counterfeit certificate, but that's why all certificates are reported in the Certificate Transparency log. If you're concerned about this, you could watch for certificates being issued with your domain name that were never in used on your servers.
  3. Again, this is the benefit of Certificate Transparency. Users could cross-check against the CT logs to ensure that any given certificate is valid. This will be slightly less effective than watching for a certificate on your domain, but in theory a rogue certificate could still be identified.

In terms of its impact on Confidentiality and Integrity, I'd be most concerned about a supply-chain attack on the tools that you use the request a Let's Encrypt certificate. The default tool - certbot - requires a great deal of access, because it's also designed to install the certificates in a variety of web servers, and the designers felt that if you are issuing certificates you should be root anyway. Fortunately, the tool is open source with over 300 direct contributors, so slipping something into the tooling would be less likely than say... slipping something into one of the libraries you use for your web application.

nbering
  • 3,988
  • 1
  • 21
  • 22
  • 4
    Maybe add that CT is cryptographically linked and not optional – John Keates Jan 12 '19 at 02:34
  • 4
    Remember also that governments often have their own CAs. – forest Jan 12 '19 at 03:03
  • 4
    What if govt. also force them to hide counterfeited certificates showing up in CT logs? – defalt Jan 12 '19 at 07:01
  • 3
    As John points out above, Certificate Transparency is not optional for CAs trusted by browsers, with Chrome leading the way on making them mandatory for validation. If a certificate is not in the transparency logs, it is not considered to be valid. That said, CT is still young in Cryptography years, so it will take time for clients to support CT validation. It's supported in OpenSSL 1.1, but a lot of software has yet to upgrade to support it. http://www.certificate-transparency.org/certificate-transparency-in-chrome – nbering Jan 12 '19 at 07:47
  • So the weakness in this system, other than the browser, hardware or software at either end, would be the Certificate Transparency log. User above (defalt) asks what if CT logs are forced to comply with tampering. An interesting point. – RealDrGordonFreeman Jan 12 '19 at 12:43
  • 5
    CT logs are a cryptographic mechanism. Attacks could be developed, but they can’t just “comply with tampering”. And omitting a certificate when the client can verify the CT log is equivalent to revoking it. – nbering Jan 12 '19 at 17:13
  • AFAIU a CT log could theoretically comply with tampering by signing a false confirmation of listing the certificate in the log. But once someone finds that, it would be easy to prove that the CT log cheats. Also, AFAIR, confirmation from multiple CT logs is required. (Maybe it would be useful to require also multiple jurisdictions…) Imagine that a government wants to force a CA to issue a counterfeit certificate and some CT logs to issue a wrong confirmation. Maybe technically doable, but it has a non-negligible risk of being caught. – v6ak Jan 19 '19 at 22:01
  • … And being caught likely means the government cannot abuse it again the same way. That's a huge hidden cost. They are not so likely to do it without a very very strong reason. buying a suitable zero-day exploit is likely cheaper. – v6ak Jan 19 '19 at 22:36
6

And

  • They could refuse to issue new certificates.
  • They could be forced to give your personal data (registration email, list of linked domains to your ACME account, IPs of your server, ...) to US Authorities.
  • They could be forced to give personal data (IPs, user-agent, ...) of the visitors of your website (using OCSP requests) to US Authorities. (OCSP staple can prevent that)
  • They could prevent some of your visitors to reach your website by refusing to answer to OCSP requests (If their browser have an hard-fail for OCSP configured. And maybe they could send a "revoked" OCSP answer only to them). OCSP staple can prevent that too

And they do post (some) stats about these requests: ISRG Legal Transparency Reports

Other related links on https://community.letsencrypt.org:

Tom
  • 2,063
  • 12
  • 19