7 ms·

TIL: DigiCert uses manual processes for issuing certs which can be taken advantage of to mis-issue them. (https://groups.google.com/forum/#!msg/mozilla.dev.secu

TIL: DigiCert uses manual processes for issuing certs which can be taken advantage of to mis-issue them. (https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/JFwqZx7RLL0/ctOjU-v5AAAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p...) Also it seems like people are leaning towards replacing WHOIS with DNS, which seems like a great fix for their operational problems, but probably a security mistake.

geofft 8y ago
Of course there are manual processes - there's a huge market for people who legitimately need certificates but cannot/will not automate everything. Otherwise everyone would have left the business after Let's Encrypt entered. You're not paying DigiCert for the cert itself - LE can give you that - you're paying them for having customer service, aka manual processes. It looks like this particular process exists because automating WHOIS lookups is hard/unreliable. An agent does a WHOIS lookup, documents it, and passes the result to other people to review. That genuinely seems to be the best way to deal with poor-quality databases that have the right data. Also it seems pretty natural to me that some business is going to ask for a certificate for www-staging.example.com or something, prove ownership in a way that happens to demonstrate ownership of example.com, and then be mad on launch day when www.example.com doesn't have a certificate too. So there should be a way for an agent to say "It looks like they control example.com" and authorize that, as long as there's review in place.
- peterwwillis 8y ago
  If "customer service" is the only thing standing in the way of certs being issued for Google.com, we're all screwed.
  - geofft 8y ago
    I mean, at the end of the day it has to be, right? In a world where everyone runs ACME, aren't there still human operators who can deploy bug fixes when Google says "Yo, why isn't our cert renewing"? Or is the plan that there's no recourse to humans, and we're all watched over by robot CAs of loving grace?
    - peterwwillis 8y ago
      It depends on what you care about more: certs being issued validly, or certs being issued? Processes can be put in place so that humans can fix problems when they find them, but also prevent a human from doing the wrong thing. Autonomation instead of automation. https://en.wikipedia.org/wiki/Autonomation https://en.wikipedia.org/wiki/Autonomation
      - geofft 8y ago
        I think it's reasonable to care more about certs being issued. Most large companies are incompetent at IT (and the reasons for this are varied and interesting but not immediately solvable), yet if they can't reliably get certificates, the plan to encrypt all web traffic falls apart. Meanwhile, Certificate Transparency monitoring mitigates the impact of mis-issuance. (Which is not to say that mis-issuance isn't great, just that it's fine to target a system that occasionally produces mis-issuances.) I guess in part I feel this way because I see HTTPS as baseline security for the web, not strong security. It's like SSH - the fact that telnet is almost completely gone is a win, even though few people really check the initial fingerprints the way they "should." In the case of both HTTPS and SSH, you can build a strong security system on top of it if you want (HPKP, pinned certs in apps, etc. for HTTPS, and distributing known_hosts files or using a private PKI or Kerberos for SSH), but the primary value is that it works reliably to the point where falling back to plaintext is unusual.
        heavenlyblue 8y ago
        >> even though few people really check the initial fingerprints the way they "should." I am yet to see a single hosting provider which doesn’t only allow you to set up your own authorizarion key in a new instance, but which also immediately gives you the generated key of the instance that you can put in the .ssh/known_hosts. So frankly it’s not just “people”.
        geofft 8y ago
        AWS (and more generally anything running cloud-init) does this fairly well - it prints it to the console log. I use this, and I have on a couple of occasions booted a new instance and mounted the old one's disk when my known_hosts file got trashed by mistake, so I could re-establish a trust path. Of course you have to know to go there, wait for the console log to sync (for some reason AWS takes a few minutes ... I wonder if it's backed by some eventual-consistency object store), and scroll down in the log. Come to think of it, it would be real cool if OpenSSH had a -o Fingerprint=ab:cd:ef... option you could pass, so that they could give you a single command to copy and paste to your terminal.
- tialaramex 8y ago
  We should avoid having human agents making these determinations because they're very bad at it. Play to human strengths. The human agent working around the fact that you keep saying "Apache" but you're actually clearly running IIS from your description is where humans are good, training an AI system to figure this out would be really hard. Figuring out that .in-addr.arpa is a Public Suffix and therefore you cannot possibly prove control over it from a Web PKI point of view is just trivial string matching and perfectly suited to a machine. We already have had incidents where a CA mistakenly took proof of control of one-name.example.com as sufficient proof of control of example.com itself and it's part of why Facebook freaked out before we had mandatory CAA (and before Facebook wrote themselves CAA records) because a sub-contractor got themselves a certificate Facebook didn't intend to exist. So no more of that please.
  - geofft 8y ago
    You should be allowed to register a public suffix - github.io is a public suffix, but the *.github.io wildcard is a perfectly legitimate certificate. And conversely facebook.com is not a public suffix, so that rule wouldn't have helped Facebook. I agree a public suffix should trigger more aggressive validation (as should, perhaps, the first request for a TLD that the CA has never issued for before), but I don't think a computerized rule blocking registration of public suffixes is appropriate.
    - tialaramex 8y ago
      The Baseline Requirements forbid issuing for Public Suffixes in what the PSL calls the "ICANN DOMAINS" section (or wildcards immediately under those suffixes). That section includes in-addr.arpa but not github.io Now, the BRs don't specifically tell you not to validate in-addr.arpa and then issue more specific certificates, but my patience wears very thin on how much needs to be spelled out letter by letter to have CAs stop doing things that are obviously a terrible idea. I can see how the juxtaposition was confusing. Facebook wasn't concerned about public suffix problems, they were worried by (a historically common) pattern where bad guys find that if they're able to persuade a CA to issue them with some-machine.example.com the same CA will then issue www.example.com to them because hey, they're from example.com... It so happened in the case that worried them that couldn't have happened, but they were not to know that.
tialaramex 8y ago
Well, this cert is OV (IV?) so it's always going to be at least semi-manual because we know the structures to truly automate OV issuance are flaky at best. The fact a DigiCert person looked at this application is unsurprising. The problem starts when that person gets to do crazy things like pick a Public Suffix as the thing being validated and gets worse when the "proof of control" is only barely related to the thing claimed. I await more from DigiCert on what was supposed to be going on here and how they'll improve. I don't buy the theory that DNS is worse than WHOIS. Even the WHOIS proponents generally try to fudge this by trying to compare RDAP, because the security considerations for WHOIS come down to "cross your fingers". In theory RDAP becomes mandatory (for the gTLDs) later this year. In practice we know the pilot programme was not exactly a roaring success and the registries have decided they'd rather the entire mechanism went away. But we'll see, I care mostly about Prevention of Future Harm, if we prevent Future Harm by going to RDAP successfully that's fine for me too.

geofft 8y ago

Of course there are manual processes - there's a huge market for people who legitimately need certificates but cannot/will not automate everything. Otherwise everyone would have left the business after Let's Encrypt entered. You're not paying DigiCert for the cert itself - LE can give you that - you're paying them for having customer service, aka manual processes. It looks like this particular process exists because automating WHOIS lookups is hard/unreliable. An agent does a WHOIS lookup, documents it, and passes the result to other people to review. That genuinely seems to be the best way to deal with poor-quality databases that have the right data. Also it seems pretty natural to me that some business is going to ask for a certificate for www-staging.example.com or something, prove ownership in a way that happens to demonstrate ownership of example.com, and then be mad on launch day when www.example.com doesn't have a certificate too. So there should be a way for an agent to say "It looks like they control example.com" and authorize that, as long as there's review in place.

peterwwillis 8y ago
If "customer service" is the only thing standing in the way of certs being issued for Google.com, we're all screwed.
- geofft 8y ago
  I mean, at the end of the day it has to be, right? In a world where everyone runs ACME, aren't there still human operators who can deploy bug fixes when Google says "Yo, why isn't our cert renewing"? Or is the plan that there's no recourse to humans, and we're all watched over by robot CAs of loving grace?
  - peterwwillis 8y ago
    It depends on what you care about more: certs being issued validly, or certs being issued? Processes can be put in place so that humans can fix problems when they find them, but also prevent a human from doing the wrong thing. Autonomation instead of automation. https://en.wikipedia.org/wiki/Autonomation https://en.wikipedia.org/wiki/Autonomation
    - geofft 8y ago
      I think it's reasonable to care more about certs being issued. Most large companies are incompetent at IT (and the reasons for this are varied and interesting but not immediately solvable), yet if they can't reliably get certificates, the plan to encrypt all web traffic falls apart. Meanwhile, Certificate Transparency monitoring mitigates the impact of mis-issuance. (Which is not to say that mis-issuance isn't great, just that it's fine to target a system that occasionally produces mis-issuances.) I guess in part I feel this way because I see HTTPS as baseline security for the web, not strong security. It's like SSH - the fact that telnet is almost completely gone is a win, even though few people really check the initial fingerprints the way they "should." In the case of both HTTPS and SSH, you can build a strong security system on top of it if you want (HPKP, pinned certs in apps, etc. for HTTPS, and distributing known_hosts files or using a private PKI or Kerberos for SSH), but the primary value is that it works reliably to the point where falling back to plaintext is unusual.
      - heavenlyblue 8y ago
        >> even though few people really check the initial fingerprints the way they "should." I am yet to see a single hosting provider which doesn’t only allow you to set up your own authorizarion key in a new instance, but which also immediately gives you the generated key of the instance that you can put in the .ssh/known_hosts. So frankly it’s not just “people”.
        geofft 8y ago
        AWS (and more generally anything running cloud-init) does this fairly well - it prints it to the console log. I use this, and I have on a couple of occasions booted a new instance and mounted the old one's disk when my known_hosts file got trashed by mistake, so I could re-establish a trust path. Of course you have to know to go there, wait for the console log to sync (for some reason AWS takes a few minutes ... I wonder if it's backed by some eventual-consistency object store), and scroll down in the log. Come to think of it, it would be real cool if OpenSSH had a -o Fingerprint=ab:cd:ef... option you could pass, so that they could give you a single command to copy and paste to your terminal.
tialaramex 8y ago
We should avoid having human agents making these determinations because they're very bad at it. Play to human strengths. The human agent working around the fact that you keep saying "Apache" but you're actually clearly running IIS from your description is where humans are good, training an AI system to figure this out would be really hard. Figuring out that .in-addr.arpa is a Public Suffix and therefore you cannot possibly prove control over it from a Web PKI point of view is just trivial string matching and perfectly suited to a machine. We already have had incidents where a CA mistakenly took proof of control of one-name.example.com as sufficient proof of control of example.com itself and it's part of why Facebook freaked out before we had mandatory CAA (and before Facebook wrote themselves CAA records) because a sub-contractor got themselves a certificate Facebook didn't intend to exist. So no more of that please.
- geofft 8y ago
  You should be allowed to register a public suffix - github.io is a public suffix, but the *.github.io wildcard is a perfectly legitimate certificate. And conversely facebook.com is not a public suffix, so that rule wouldn't have helped Facebook. I agree a public suffix should trigger more aggressive validation (as should, perhaps, the first request for a TLD that the CA has never issued for before), but I don't think a computerized rule blocking registration of public suffixes is appropriate.
  - tialaramex 8y ago
    The Baseline Requirements forbid issuing for Public Suffixes in what the PSL calls the "ICANN DOMAINS" section (or wildcards immediately under those suffixes). That section includes in-addr.arpa but not github.io Now, the BRs don't specifically tell you not to validate in-addr.arpa and then issue more specific certificates, but my patience wears very thin on how much needs to be spelled out letter by letter to have CAs stop doing things that are obviously a terrible idea. I can see how the juxtaposition was confusing. Facebook wasn't concerned about public suffix problems, they were worried by (a historically common) pattern where bad guys find that if they're able to persuade a CA to issue them with some-machine.example.com the same CA will then issue www.example.com to them because hey, they're from example.com... It so happened in the case that worried them that couldn't have happened, but they were not to know that.

tialaramex 8y ago

Well, this cert is OV (IV?) so it's always going to be at least semi-manual because we know the structures to truly automate OV issuance are flaky at best. The fact a DigiCert person looked at this application is unsurprising. The problem starts when that person gets to do crazy things like pick a Public Suffix as the thing being validated and gets worse when the "proof of control" is only barely related to the thing claimed. I await more from DigiCert on what was supposed to be going on here and how they'll improve. I don't buy the theory that DNS is worse than WHOIS. Even the WHOIS proponents generally try to fudge this by trying to compare RDAP, because the security considerations for WHOIS come down to "cross your fingers". In theory RDAP becomes mandatory (for the gTLDs) later this year. In practice we know the pilot programme was not exactly a roaring success and the registries have decided they'd rather the entire mechanism went away. But we'll see, I care mostly about Prevention of Future Harm, if we prevent Future Harm by going to RDAP successfully that's fine for me too.