6 ms·

Improving the quality of publicly trusted intermediate CA certificates

88 points by floatingatoll 5y ago

pas 5y ago
"[...] we will begin to also require disclosure of intermediate certificates that are capable of issuing websites (TLS/SSL) or email (S/MIME) certificates even when they are technically constrained." tl;dr all interCAs have to be reported (right? or am I missing something?)
- floatingatoll 5y ago
  I haven’t researched this fully yet, but I believe that this is a nuance of x509 and certificate purposes. If the intermediate is granted the permission “issue website/email cert” at the lowest x509 level, then it apparently (TIL) used to be possible to layer in higher-level constraints in order to disable that so as not to disclose it — but when these rules take effect, that kind of exception will no longer be accepted, since intermediates that won’t be issuing web/email certificates shouldn’t be issued with x509 properties that say “I can issue web/email certificates” anyways.
- tialaramex 5y ago
  Previously, Mozilla's requirement to be informed of intermediate CAs explicitly did not include "technically constrained" CAs. "Technically constrained" refers to properties of the signed CA certificate which would cause a correct PKIX implementation to either reject the certificate (because they know they don't understand something important about it) or obey some restriction when trusting it, a constraint on how it can be used. In particular constraints are used to say things like "This intermediate must only issue for names ending in .famous.example" or "This intermediate may not issue for names ending in .different.example". In practice we also use the X.509 Extended Key Usage fields of CA certificates as constraints, even though probably we shouldn't that's settled practice and can't realistically be fixed now. So, if the intermediate's certificate has an EKU saying its key has "Any Use" the interpretation today is that it can be used to sign other certificates with any use. After the policy change, most intermediate CAs will need to be disclosed. But, an intermediate that can't be used to issue working certificates in the Web PKI or for S/MIME could still exist under these rules. For example if you have ended up with some legacy system that needs a CA primarily used in the Web PKI but you're doing SpecialThing with it, in principle a subCA under that CA constrained by an EKU saying only SpecialThing usage is allowed, would still not need to be disclosed since it can't cause harm: A "real" SpecialThing certificate isn't a TLS certificate, and bad guys who subvert the SpecialThing intermediate can't issue working TLS certificates either. Mozilla primarily cares about Firefox users, so, they don't need to care that in theory your badly designed TLS client might not check EKUs, Firefox does.
FiloSottile 5y ago
As part of this effort, Mozilla requires disclosure of all intermediate CA certificates in the WebPKI. They bundle that list in Firefox, so that even if a server is misconfigured and sends the wrong certificate chain (but a valid leaf certificate), they can successfully establish a TLS connection. It's pretty cool, and less confusing than the caching approach of other browsers, which leads to non-deterministic behavior. Using the list they publish [1] I built a Go package that provides the same feature, as both a x509.CertPool or a tls.VerifyConnection callback, to allow clients to connect to misconfigured servers: https://pkg.go.dev/filippo.io/intermediates https://pkg.go.dev/filippo.io/intermediates The pool is regenerated [2] by a GitHub Action [3] every night, and embedded into the package so it requires no network connection. If tests fail on the new pool, it doesn't get committed. It's actually kinda interesting watching the intermediates come and go [4], and it's very satisfying to have a self-maintaining package. [1] https://ccadb-public.secure.force.com/mozilla/MozillaIntermediateCertsCSVReport https://ccadb-public.secure.force.com/mozilla/MozillaInterme... [2] https://github.com/FiloSottile/intermediates/blob/7dfa9179/generate.go https://github.com/FiloSottile/intermediates/blob/7dfa9179/g... [3] https://github.com/FiloSottile/intermediates/blob/7dfa91796/.github/workflows/generate.yml https://github.com/FiloSottile/intermediates/blob/7dfa91796/... [4] https://github.com/FiloSottile/intermediates/commits/main https://github.com/FiloSottile/intermediates/commits/main
- tialaramex 5y ago
  I would have liked the world where AIA chasing happened in servers. Today several browsers which don't have Mozilla's list of intermediates instead (if they don't have a satisfactory chain offered to them) do AIA chasing, meaning that the browser consults the Authority Information Access fields in the X.509 certificate, finds a URL in there and fetches that URL hoping to get a certificate it trusts, often it iterates several times before giving up or reaching a dead end. AIA chasing in browsers is a (small) privacy risk and a (non-trivial) performance cost, plus it can just fail if you don't have as much Internet access, perhaps because you need to talk to a server, whose certificate you are trying to validate, before getting access; or of course it can just fail because temporarily some server is down somewhere. If server software did AIA chasing (e.g. nginx, or your SMTP server) it would see during startup that you configured a bare certificate, and do the same AIA chasing that browsers do today but only once for the lifetime of the service and with the privilege of being a server (likely better Internet access, and more likely somebody technical sees the error output if there are problems) and it could have retry/fallback behaviour and if it doesn't work well the server can tell its administrator to fix the problem, whereas the browser doesn't have a way to contact that admin. But Mozilla's choice here was pragmatic. We get the world we deserve.
jcims 5y ago
Does anyone in here know what the fundamental driver for this is? Is there a specific risk being addressed or is this just trying to create a more uniform governance model for intermediates? The third party aspect definitely sounds like it’s reacting to something. BTW the linked mailing list is interesting reading if you’re into this stuff.
- zibzab 5y ago
  Mozilla has invested tons of resources in improving web security, sometimes even when it hurts them. A good examples is the anti-tracking stuff that break some badly coded (sometimes intentionally!) pages. Users may have left FF for chrome thinking it was not compatible with their favourite sites. Anyway, if you are a web developer please test your code with FF and anti-tracking enabled (Mozilla has some good documentation on this). If you are a user make sure to contact site owners and complain instead of just going to a less privacy preserving browser. (Not saying mozilla is perfect, they also try to do some shady stuff sometimes. But right now at least their privacy/security teams are doing some really nice things) Edit: going back to your original question, yes there have been incidents. And some outright abuse.
denton-scratch 5y ago
"Automated audit" sounds to me like an oxymoron.
- tialaramex 5y ago
  Audit isn't automated, it's often done by local "professional services" firms (often from the Big Four) on site and is the least useful tool we have but is better than nothing. However Mozilla's processing of audit documents created by that audit is (somewhat) automated. Here's an example task we can give to a machine: We want audit letters to be for the correct period of time, and mention all the correct CAs. So, look through the letter and find the dates, and the identifiers for the CAs, and check they match what's expected. If they don't flag for the CA to get us a suitable letter. This catches the case where the CA sent us the 2019 letter again or a letter doesn't mention all their intermediates. We don't need to care why that happened at this stage, we just want to ensure it can't happen. Humans are mostly not evil, but they are lazy, incompetent, and sometimes greedy. Automated checking covers those problems pretty well. Auditors are often reluctant to lie for you, but they're usually willing to omit facts you'd prefer weren't mentioned. Audit of AB1235 shows big problems? Just write that audit of AA1234 and AB1234 were fine and omit all mention of AB1235 from the letter. The automated check will pull that up, why isn't AB1235 mentioned?
  - denton-scratch 5y ago
    Thank you for the explanation. So an automated audit isn't really an automated audit, it's a manual audit for which the audit report is checked automatically.
    - tialaramex 5y ago
      I think the problem is you've parsed the sentence wrong. The phrase Mozilla uses is "Automated Audit Letter Validation" and you've said to yourself, oh, there's an "Automated Audit" and this is validation of letters connected with that. Nope. There are "Audit Letters" - letters reporting the outcome of each audit - and they need to be Validated, now Mozilla has Automated part of that work. Judging from other reactions I think the vast majority of people parsed this correctly in context, though it's possible I'm wrong. Occasionally poor editing will result in text that most native speakers parse wrongly, these are named "Crash Blossoms" from the naming example headline, "Violinist linked to JAL crash blossoms". A violinist (metaphorically) blossomed, and the headline is explaining which one by telling us it's the one "linked to JAL crash". This bug (statements which have ambiguous parsing) is probably unavoidable in natural languages, although similar bugs in programming languages are arguably a design mistake.

88 points by floatingatoll 5y ago

pas 5y ago

"[...] we will begin to also require disclosure of intermediate certificates that are capable of issuing websites (TLS/SSL) or email (S/MIME) certificates even when they are technically constrained." tl;dr all interCAs have to be reported (right? or am I missing something?)

floatingatoll 5y ago
I haven’t researched this fully yet, but I believe that this is a nuance of x509 and certificate purposes. If the intermediate is granted the permission “issue website/email cert” at the lowest x509 level, then it apparently (TIL) used to be possible to layer in higher-level constraints in order to disable that so as not to disclose it — but when these rules take effect, that kind of exception will no longer be accepted, since intermediates that won’t be issuing web/email certificates shouldn’t be issued with x509 properties that say “I can issue web/email certificates” anyways.
tialaramex 5y ago
Previously, Mozilla's requirement to be informed of intermediate CAs explicitly did not include "technically constrained" CAs. "Technically constrained" refers to properties of the signed CA certificate which would cause a correct PKIX implementation to either reject the certificate (because they know they don't understand something important about it) or obey some restriction when trusting it, a constraint on how it can be used. In particular constraints are used to say things like "This intermediate must only issue for names ending in .famous.example" or "This intermediate may not issue for names ending in .different.example". In practice we also use the X.509 Extended Key Usage fields of CA certificates as constraints, even though probably we shouldn't that's settled practice and can't realistically be fixed now. So, if the intermediate's certificate has an EKU saying its key has "Any Use" the interpretation today is that it can be used to sign other certificates with any use. After the policy change, most intermediate CAs will need to be disclosed. But, an intermediate that can't be used to issue working certificates in the Web PKI or for S/MIME could still exist under these rules. For example if you have ended up with some legacy system that needs a CA primarily used in the Web PKI but you're doing SpecialThing with it, in principle a subCA under that CA constrained by an EKU saying only SpecialThing usage is allowed, would still not need to be disclosed since it can't cause harm: A "real" SpecialThing certificate isn't a TLS certificate, and bad guys who subvert the SpecialThing intermediate can't issue working TLS certificates either. Mozilla primarily cares about Firefox users, so, they don't need to care that in theory your badly designed TLS client might not check EKUs, Firefox does.

FiloSottile 5y ago

As part of this effort, Mozilla requires disclosure of all intermediate CA certificates in the WebPKI. They bundle that list in Firefox, so that even if a server is misconfigured and sends the wrong certificate chain (but a valid leaf certificate), they can successfully establish a TLS connection. It's pretty cool, and less confusing than the caching approach of other browsers, which leads to non-deterministic behavior. Using the list they publish [1] I built a Go package that provides the same feature, as both a x509.CertPool or a tls.VerifyConnection callback, to allow clients to connect to misconfigured servers: https://pkg.go.dev/filippo.io/intermediates https://pkg.go.dev/filippo.io/intermediates The pool is regenerated [2] by a GitHub Action [3] every night, and embedded into the package so it requires no network connection. If tests fail on the new pool, it doesn't get committed. It's actually kinda interesting watching the intermediates come and go [4], and it's very satisfying to have a self-maintaining package. [1] https://ccadb-public.secure.force.com/mozilla/MozillaIntermediateCertsCSVReport https://ccadb-public.secure.force.com/mozilla/MozillaInterme... [2] https://github.com/FiloSottile/intermediates/blob/7dfa9179/generate.go https://github.com/FiloSottile/intermediates/blob/7dfa9179/g... [3] https://github.com/FiloSottile/intermediates/blob/7dfa91796/.github/workflows/generate.yml https://github.com/FiloSottile/intermediates/blob/7dfa91796/... [4] https://github.com/FiloSottile/intermediates/commits/main https://github.com/FiloSottile/intermediates/commits/main

tialaramex 5y ago
I would have liked the world where AIA chasing happened in servers. Today several browsers which don't have Mozilla's list of intermediates instead (if they don't have a satisfactory chain offered to them) do AIA chasing, meaning that the browser consults the Authority Information Access fields in the X.509 certificate, finds a URL in there and fetches that URL hoping to get a certificate it trusts, often it iterates several times before giving up or reaching a dead end. AIA chasing in browsers is a (small) privacy risk and a (non-trivial) performance cost, plus it can just fail if you don't have as much Internet access, perhaps because you need to talk to a server, whose certificate you are trying to validate, before getting access; or of course it can just fail because temporarily some server is down somewhere. If server software did AIA chasing (e.g. nginx, or your SMTP server) it would see during startup that you configured a bare certificate, and do the same AIA chasing that browsers do today but only once for the lifetime of the service and with the privilege of being a server (likely better Internet access, and more likely somebody technical sees the error output if there are problems) and it could have retry/fallback behaviour and if it doesn't work well the server can tell its administrator to fix the problem, whereas the browser doesn't have a way to contact that admin. But Mozilla's choice here was pragmatic. We get the world we deserve.

jcims 5y ago

Does anyone in here know what the fundamental driver for this is? Is there a specific risk being addressed or is this just trying to create a more uniform governance model for intermediates? The third party aspect definitely sounds like it’s reacting to something. BTW the linked mailing list is interesting reading if you’re into this stuff.

zibzab 5y ago
Mozilla has invested tons of resources in improving web security, sometimes even when it hurts them. A good examples is the anti-tracking stuff that break some badly coded (sometimes intentionally!) pages. Users may have left FF for chrome thinking it was not compatible with their favourite sites. Anyway, if you are a web developer please test your code with FF and anti-tracking enabled (Mozilla has some good documentation on this). If you are a user make sure to contact site owners and complain instead of just going to a less privacy preserving browser. (Not saying mozilla is perfect, they also try to do some shady stuff sometimes. But right now at least their privacy/security teams are doing some really nice things) Edit: going back to your original question, yes there have been incidents. And some outright abuse.

denton-scratch 5y ago

"Automated audit" sounds to me like an oxymoron.

tialaramex 5y ago
Audit isn't automated, it's often done by local "professional services" firms (often from the Big Four) on site and is the least useful tool we have but is better than nothing. However Mozilla's processing of audit documents created by that audit is (somewhat) automated. Here's an example task we can give to a machine: We want audit letters to be for the correct period of time, and mention all the correct CAs. So, look through the letter and find the dates, and the identifiers for the CAs, and check they match what's expected. If they don't flag for the CA to get us a suitable letter. This catches the case where the CA sent us the 2019 letter again or a letter doesn't mention all their intermediates. We don't need to care why that happened at this stage, we just want to ensure it can't happen. Humans are mostly not evil, but they are lazy, incompetent, and sometimes greedy. Automated checking covers those problems pretty well. Auditors are often reluctant to lie for you, but they're usually willing to omit facts you'd prefer weren't mentioned. Audit of AB1235 shows big problems? Just write that audit of AA1234 and AB1234 were fine and omit all mention of AB1235 from the letter. The automated check will pull that up, why isn't AB1235 mentioned?
- denton-scratch 5y ago
  Thank you for the explanation. So an automated audit isn't really an automated audit, it's a manual audit for which the audit report is checked automatically.
  - tialaramex 5y ago
    I think the problem is you've parsed the sentence wrong. The phrase Mozilla uses is "Automated Audit Letter Validation" and you've said to yourself, oh, there's an "Automated Audit" and this is validation of letters connected with that. Nope. There are "Audit Letters" - letters reporting the outcome of each audit - and they need to be Validated, now Mozilla has Automated part of that work. Judging from other reactions I think the vast majority of people parsed this correctly in context, though it's possible I'm wrong. Occasionally poor editing will result in text that most native speakers parse wrongly, these are named "Crash Blossoms" from the naming example headline, "Violinist linked to JAL crash blossoms". A violinist (metaphorically) blossomed, and the headline is explaining which one by telling us it's the one "linked to JAL crash". This bug (statements which have ambiguous parsing) is probably unavoidable in natural languages, although similar bugs in programming languages are arguably a design mistake.