5 ms·

For a while I found it funny that the web's security is based on the strength of (1) new standards from Let's Encrypt, and (2) the quality of their codebase. It

For a while I found it funny that the web's security is based on the strength of (1) new standards from Let's Encrypt, and (2) the quality of their codebase. It's been shown multiple times that they have failed in both of these, yet nobody has taken them to task as failing to uphold the responsibility that CAs have to keep the web secure. (https://community.letsencrypt.org/c/incidents https://community.letsencrypt.org/c/incidents) At first I thought that their biggest issue was properly verifying that a domain owner is requesting a certificate (they don't do that, but anyway..). They actually have multiple categories of security holes relating to web pki, because it's a pretty big sandbox. The holes affecting LE include everything from OCSP support, to actually not issuing any certificates during Google outages (yes, if Google is down, LE is down, as well as other CAs, and it's happened multiple times), to exposing the personal information of LE users, to bugs in their protocol allowing any cert to be issued, to mis-handling blocklists, leaking API keys, and so on. Basically, a litany of different security holes could at any time compromise the security of the whole damn web. The thing is, this isn't specific just to LE. All these things and more probably affect every CA. LE is just more experimental and new, using less robust infrastructure and technology, and their "growing pains" provide a much more visible and much wider attack surface for abusing PKI. I don't think the industry organizations connected to CAs care enough to put in stringent security practices in place. But I do think it's about time to start producing these standards. It's probably going to be up to hobbyists and privacy aficionados to do this work, because they're the ones who care enough. I'm also surprised that governments aren't more active in enforcing more stringent security practices, seeing as they're affected just as much. Interestingly, following the CT Policy mailing list is a good way to be told about holes in the current CA system: https://groups.google.com/a/chromium.org/d/msg/ct-policy/_csiMYrwsxc/2S6bMnSCDwAJ https://groups.google.com/a/chromium.org/d/msg/ct-policy/_cs...

annonch 8y ago
Hmm you may be right in general but this post is about a vulnerability in a specification adopted by LE not a standard designed by LE.
- schoen 8y ago
  TLS-SNI-01 and ACME were both originally invented by Let's Encrypt, and have still not (quite) been standardized by IETF.
schoen 8y ago
> All these things and more probably affect every CA. LE is just more experimental and new, using less robust infrastructure and technology, and their "growing pains" provide a much more visible and much wider attack surface for abusing PKI. I think you're also leaving out that LE is more proactive about finding and disclosing problems. Many of the other CAs that encounter similar problems don't write blog posts about them.
- peterwwillis 8y ago
  Is that supposed to reassure me, or reinforce my point that all of this is a huge mess that's probably trivial to compromise?
  - schoen 8y ago
    That's up to you! I'm a PKI skeptic who's now working in PKI and my impression is that everything is getting better quickly -- partly thanks to stepped-up scrutiny and enforcement on the browser side, led by Google. You could look at the "getting better quickly" part and be happy about that, or look at where we started from and be unhappy about that, maybe like several other things in the world.
  - jcoffland 8y ago
    > all of this is a huge mess that's probably trivial to compromise? That's a bold claim. I think you should prove it otherwise it's just FUD. By prove it, I mean perform an exploit and documented it. That's the only way things get better.
    - peterwwillis 8y ago
      It's not FUD when you have a list of incidents (https://community.letsencrypt.org/c/incidents https://community.letsencrypt.org/c/incidents) and it's not FUD just because I don't have 0days sitting around. If this is just the incidents from one CA, and assuming this is an example of best effort, there would naturally be many more, and possibly worse, exploits gone unnoticed on the hundreds of other CAs.
profmonocle 8y ago
> At first I thought that their biggest issue was properly verifying that a domain owner is requesting a certificate (they don't do that, but anyway..). Why would they? That's not what web PKI standards require. It's not necessary to demonstrate ownership of the domain, only control of the domain. If only the owner could request a certificate, then many valid use cases would be impossible. i.e. if I use a blogging service to host blog.company.com, they can use Let's Encrypt (or another CA) to manage the cert for me. If domain owners had to manually renew these certs themselves and upload them, HTTPS adoption would be much lower on these types of services. Requiring proof of ownership also wouldn't take into account that DNS hierarchy sometimes extends below what WHOIS can reveal. For instance, a company may delegate department.company.com to some internal sub-group. That sub-group wouldn't be able to manage their own certs if they had to own the registered domain, as shown in whois. > I don't think the industry organizations connected to CAs care enough to put in stringent security practices in place. This simply isn't true. There's an extremely thorough set of requirements called the "baseline requirements" that every CA must follow. These are written by the CAB forum, which is an industry group comprised of browser/OS vendors and CAs.
- schoen 8y ago
  I imagine Peter's view may be that the BRs aren't stringent enough and also aren't enforced well enough.
- peterwwillis 8y ago
  tl;dr it's not impossible and we can delegate requests. > If only the owner could request a certificate, then many valid use cases would be impossible. i.e. if I use a blogging service to host blog.company.com, they can use Let's Encrypt (or another CA) to manage the cert for me. If domain owners had to manually renew these certs themselves and upload them, HTTPS adoption would be much lower on these types of services. It's not impossible, and wouldn't even be that difficult, just a few extra steps for LE and the registrar, and one extra step for the domain owner. It would work like this: Step 1) Domain Owner signs up for a blog on SomeBlogSite.com with their own domain "mycoolrecipes.com" and sets up the DNS record ("mycoolrecipes.com. IN A <sbo IP address here>") Step 2) SBO wants to gen a cert for mycoolrecipes.com, so they request one from LE. Step 3) LE goes to the registrar for mycoolrecipes.com and says "Hey, some random blog is trying to get a cert, is this cool? " Step 4) Registrar sends an e-mail to DO saying, "Hey, is this cool? I know your DNS is pointed at SBO, but I wanted to make sure you actually authorize SBO to handle your security, and not just random network services. Click this link and log in to verify they get the cert." Step 5) DO logs in to registrar, verifies SBO can have the cert. Step 6) Registrar notifies LE they can have the cert. Step 7) LE releases cert to SBO. This has the effect of 1) removing almost all invisible attacks on cert issuance, because the [delegated] owner has to see and authorize the request, 2) preventing the current need for Certificate Transparency; Registrars could still feed the logs, but CAs wouldn't have to, because the registrar (and domain owner) is the final arbiter, 3) preventing the need for CAA (which doesn't necessarily work anyway and is opt-in), and 4) preventing attacks on DNS from compromising cert issuance. You can also do this with keys and not e-mails, so that it happens automatically, but only keys authorized by the DO can gen certs. Meaning we have cryptographic proof that only SBO can gen certs for DO, and only with that one CA. Which is way more secure than the current regime. (Again: nobody should be depending on DNS, DNS sucks, and DNS records don't prove domain ownership, nor that you want anything DNS points to at any time to control your security) > Requiring proof of ownership also wouldn't take into account that DNS hierarchy sometimes extends below what WHOIS can reveal. For instance, a company may delegate department.company.com to some internal sub-group. That sub-group wouldn't be able to manage their own certs if they had to own the registered domain, as shown in whois. For companies with DNS delegation, registrars can provide more fine-grained delegation features, or companies can integrate a DNS management API to delegate authorization of certs. There are at least two open source DNS management APIs (that work independently of who controls the authoritative DNS server) and can control pre-created zones based on users, groups, and access policies. Registrars can make the request for the FQDN to the main domain and the domain can pass it on as needed. So all of that already exists, it would just need one new API function to handle authorizing certificate issuance. DNS is a hierarchy, so delegating control like this should be expected. Otherwise, use different top level domains. And schoen is correct, I don't think the BRs are nearly enough. There are security best practices that are going ignored and would catch a lot of the mistakes perpetrated by integration and operation teams.

annonch 8y ago

Hmm you may be right in general but this post is about a vulnerability in a specification adopted by LE not a standard designed by LE.

schoen 8y ago
TLS-SNI-01 and ACME were both originally invented by Let's Encrypt, and have still not (quite) been standardized by IETF.

schoen 8y ago

> All these things and more probably affect every CA. LE is just more experimental and new, using less robust infrastructure and technology, and their "growing pains" provide a much more visible and much wider attack surface for abusing PKI. I think you're also leaving out that LE is more proactive about finding and disclosing problems. Many of the other CAs that encounter similar problems don't write blog posts about them.

peterwwillis 8y ago
Is that supposed to reassure me, or reinforce my point that all of this is a huge mess that's probably trivial to compromise?
- schoen 8y ago
  That's up to you! I'm a PKI skeptic who's now working in PKI and my impression is that everything is getting better quickly -- partly thanks to stepped-up scrutiny and enforcement on the browser side, led by Google. You could look at the "getting better quickly" part and be happy about that, or look at where we started from and be unhappy about that, maybe like several other things in the world.
- jcoffland 8y ago
  > all of this is a huge mess that's probably trivial to compromise? That's a bold claim. I think you should prove it otherwise it's just FUD. By prove it, I mean perform an exploit and documented it. That's the only way things get better.
  - peterwwillis 8y ago
    It's not FUD when you have a list of incidents (https://community.letsencrypt.org/c/incidents https://community.letsencrypt.org/c/incidents) and it's not FUD just because I don't have 0days sitting around. If this is just the incidents from one CA, and assuming this is an example of best effort, there would naturally be many more, and possibly worse, exploits gone unnoticed on the hundreds of other CAs.

profmonocle 8y ago

> At first I thought that their biggest issue was properly verifying that a domain owner is requesting a certificate (they don't do that, but anyway..). Why would they? That's not what web PKI standards require. It's not necessary to demonstrate ownership of the domain, only control of the domain. If only the owner could request a certificate, then many valid use cases would be impossible. i.e. if I use a blogging service to host blog.company.com, they can use Let's Encrypt (or another CA) to manage the cert for me. If domain owners had to manually renew these certs themselves and upload them, HTTPS adoption would be much lower on these types of services. Requiring proof of ownership also wouldn't take into account that DNS hierarchy sometimes extends below what WHOIS can reveal. For instance, a company may delegate department.company.com to some internal sub-group. That sub-group wouldn't be able to manage their own certs if they had to own the registered domain, as shown in whois. > I don't think the industry organizations connected to CAs care enough to put in stringent security practices in place. This simply isn't true. There's an extremely thorough set of requirements called the "baseline requirements" that every CA must follow. These are written by the CAB forum, which is an industry group comprised of browser/OS vendors and CAs.

schoen 8y ago
I imagine Peter's view may be that the BRs aren't stringent enough and also aren't enforced well enough.
peterwwillis 8y ago
tl;dr it's not impossible and we can delegate requests. > If only the owner could request a certificate, then many valid use cases would be impossible. i.e. if I use a blogging service to host blog.company.com, they can use Let's Encrypt (or another CA) to manage the cert for me. If domain owners had to manually renew these certs themselves and upload them, HTTPS adoption would be much lower on these types of services. It's not impossible, and wouldn't even be that difficult, just a few extra steps for LE and the registrar, and one extra step for the domain owner. It would work like this: Step 1) Domain Owner signs up for a blog on SomeBlogSite.com with their own domain "mycoolrecipes.com" and sets up the DNS record ("mycoolrecipes.com. IN A <sbo IP address here>") Step 2) SBO wants to gen a cert for mycoolrecipes.com, so they request one from LE. Step 3) LE goes to the registrar for mycoolrecipes.com and says "Hey, some random blog is trying to get a cert, is this cool? " Step 4) Registrar sends an e-mail to DO saying, "Hey, is this cool? I know your DNS is pointed at SBO, but I wanted to make sure you actually authorize SBO to handle your security, and not just random network services. Click this link and log in to verify they get the cert." Step 5) DO logs in to registrar, verifies SBO can have the cert. Step 6) Registrar notifies LE they can have the cert. Step 7) LE releases cert to SBO. This has the effect of 1) removing almost all invisible attacks on cert issuance, because the [delegated] owner has to see and authorize the request, 2) preventing the current need for Certificate Transparency; Registrars could still feed the logs, but CAs wouldn't have to, because the registrar (and domain owner) is the final arbiter, 3) preventing the need for CAA (which doesn't necessarily work anyway and is opt-in), and 4) preventing attacks on DNS from compromising cert issuance. You can also do this with keys and not e-mails, so that it happens automatically, but only keys authorized by the DO can gen certs. Meaning we have cryptographic proof that only SBO can gen certs for DO, and only with that one CA. Which is way more secure than the current regime. (Again: nobody should be depending on DNS, DNS sucks, and DNS records don't prove domain ownership, nor that you want anything DNS points to at any time to control your security) > Requiring proof of ownership also wouldn't take into account that DNS hierarchy sometimes extends below what WHOIS can reveal. For instance, a company may delegate department.company.com to some internal sub-group. That sub-group wouldn't be able to manage their own certs if they had to own the registered domain, as shown in whois. For companies with DNS delegation, registrars can provide more fine-grained delegation features, or companies can integrate a DNS management API to delegate authorization of certs. There are at least two open source DNS management APIs (that work independently of who controls the authoritative DNS server) and can control pre-created zones based on users, groups, and access policies. Registrars can make the request for the FQDN to the main domain and the domain can pass it on as needed. So all of that already exists, it would just need one new API function to handle authorizing certificate issuance. DNS is a hierarchy, so delegating control like this should be expected. Otherwise, use different top level domains. And schoen is correct, I don't think the BRs are nearly enough. There are security best practices that are going ignored and would catch a lot of the mistakes perpetrated by integration and operation teams.