5 ms·

CAs have been caught issuing CA=YES certificates and Mozilla have done nothing. https://bugzilla.mozilla.org/show_bug.cgi?id=724929 https://bugzilla.mozilla.or

CAs have been caught issuing CA=YES certificates and Mozilla have done nothing. https://bugzilla.mozilla.org/show_bug.cgi?id=724929 https://bugzilla.mozilla.org/show_bug.cgi?id=724929 WONTFIX

jasonjei 10y ago
I think Chinese CAs are also special cases. If American browser vendors remove a Chinese CA like WoSign, there is the possibility a fork distribution will replace Mozilla in China by inclusion of these certificates. I think it would take the cooperation of the Big 4 browser/OS vendors to remove a CA, and the Chinese market often responds by creating its own internal distribution.
- deleted 10y ago
  [deleted]
- amluto 10y ago
  But Firefox probably could name-constrain WoSign to .cn. Firefox could probably also name-constrain all StartCom-issued certificates after some cut-off-date to .cn or just ban new StartCom-issued certificates entirely.
  - richardwhiuk 10y ago
    Banning due to cut-off dates is difficult when the CA has been shown to back-date certificates.
  - tptacek 10y ago
    Reprising a previous comment about this suggestion: This is one of those ideas that sounds like common sense when you hear or think about it the first time, but falls apart on scrutiny. Ryan Sleevi has done a much better job picking it apart than I can here, but among the numerous problems with it: * The most important TLDs are transnational, and their trust hierarchies back into corporations (corporations, I will cheerfully and without irony point out, who are subject to the whims of the FVEY IC). * It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism. * It consigns residents of countries with oppressive governments to total control by their governments, while at the same time making usage constraints based on those TLDs (such as local mandates to use services whose names end in .XX for XX in $bad_countries) much more powerful. * It further promotes the idea that security should somehow be tied to the DNS, despite the fact that the DNS is itself not transparently managed, and is often managed at odds with the interests of Internet users as a whole. * By factionalizing Internet trust, it harms interoperability and also makes it harder to introduce further constraints into the certificate system by essentially declaring up front that we're conceding Internet trust policy to individual nations. * It greatly complicates the security stories of companies that have adopted vanity domain names in random countries, which, whatever you think of those companies (koff! Pinboard), is an unforced error. Of all the things we can spend time on to improve Internet security, this is not one of the better ones.
    - idlewords 10y ago
      Let's see if you still think my .IN "vanity" domain is a mistake come November 9. I'm putting my chips on the world's biggest democracy!
      - tptacek 10y ago
        HE'S NOT GOING TO WIN EVERYTHING WILL BE FINE SHUT UP
        trump4president 10y ago
        I will win and put you behind a wall that you will pay for!
    - wtbob 10y ago
      > The most important TLDs are transnational, and their trust hierarchies back into corporations (corporations, I will cheerfully and without irony point out, who are subject to the whims of the FVEY IC). Are they? I always thought that .com, .edu, .net et al. are American. I suppose one could argue that .eu is transnational, although the EU are trying very hard to invent their own postmodern nation. > It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism. It's not really jingoism, although it might be nationalism. And is it even nationalism, when each nation-state makes its corporate decisions in a manner which is acceptable to the members of said state? > It consigns residents of countries with oppressive governments to total control by their governments … which they already are under, so it doesn't make anything worse. And they are, of course, free to revolt, as oppressed peoples have done throughout history, sometimes succeeding and sometimes failing. > By factionalizing Internet trust You say factionalising, I say federating. It doesn't make any sense to me for a corporation in Canada to certify the identity of a site in Iran for a resident of Guinea-Bissau, which is the current situation. Federation seems to me to be the only solution capable of scaling to a world of billions. > It greatly complicates the security stories of companies that have adopted vanity domain names in random countries I think the unforced error was placing their identities in the hands of foreign states. And, of course, with domain-level validation, their security is already in the hands of those states.
  - cpeterso 10y ago
    WoSign issues certificates for domains outside .cn.
- niftich 10y ago
  This is PKI at its worst; when the incentives of a particular user's trust delegate (the browser) don't align with that of the user.
  - tptacek 10y ago
    ... which is to say, it describes all tree-structured PKIs. (I agree).
agwa 10y ago
That was the first and only CA to be excused for that. When ANSSI did it, they got name-constrained to French TLDs only: https://bugzilla.mozilla.org/show_bug.cgi?id=952572 https://bugzilla.mozilla.org/show_bug.cgi?id=952572 When CNNIC did it, they were distrusted: https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/ https://blog.mozilla.org/security/2015/04/02/distrusting-new...
- revelation 10y ago
  Right, because the security of the CA system is a game of probability. No, one bad apple spoils the haul.
  - agwa 10y ago
    Probability has nothing to do with it. Trustwave was excused because what they were doing was not expressly prohibited at the time and other CAs were probably doing the same thing. Trustwave proactively came forward about what they had done. They shouldn't have been the only ones to be distrusted as a result. CAs are not going to be excused for this again, as CNNIC and ANNSI show.
    - revelation 10y ago
      It was not expressly prohibited to have third parties sign a certificate for google.com? Security isn't some taxation game where you find a loophole for your weekend car in the rules, it's about outcomes.
      - tptacek 10y ago
        No, it wasn't. That's because the certificates we're talking about were intended to substitute for Google's. They were for enterprise networks, some of them with legal requirements to monitor outgoing traffic (Google Mail in particular is a big problem at regulated financial firms.) The CA=YES certificates were housed in DLP and proxy appliances that ran only on the borders of their own networks. Enterprises wanted these certificates because the alternative to them is installing additional root certificates on everyone's desktop machines, which is a logistical pain. I'm not excusing that CA transaction. Issuing CA=YES certificates as a convenience for enterprise security teams is terribly irresponsible, and never should have been allowed. But, at the the the Trustwave thing happened, it was not expressly black-letter against the rules, and so Trustwave didn't get the CA death penalty for it. They would, supposedly, if they did it again.
geofft 10y ago
IIRC, that happened when it was not totally clear that a CA shouldn't be doing that. That incident made it clear that such a thing was in fact prohibited by Mozilla policy, and the CA in question revoked the cert. If it happens again, I would expect the CA (regardless of size) to be revoked—but at the same time, I would expect the big CAs to know they shouldn't even think of it now, which apparently they didn't know in 2012. "WONTFIX" is the technical status of the Bugzilla bug, because there wasn't a code change, but it's clear that Mozilla took a policy action: > I have posted a draft CA Communication in the mozilla.dev.security.policy forum for review/discussion. My intent is to make it clear that this type of behavior will not be tolerated for subCAs chaining to roots in NSS, give all CAs fair warning and a grace period, and state the consequences if such behavior is found after that grace period. There is also an action item for CAs to update their CP/CPS to make it clear that they will not issue subCAs for this purpose. (That also happened when the browser world was less good at dealing with bad CAs, in general)
- revelation 10y ago
  Incredulous. This is a CA signing away their business and you make it sound like some kind of policy misunderstanding. No, that can not stand.
  - geofft 10y ago
    It absolutely was a policy misunderstanding in 2012. It is no longer a misunderstanding, since it is now abundantly clear to CAs that they can't do that. It no longer stands. As far as CA policy goes, 2012 was the very distant past. You might as well accuse Mozilla of poor judgment for allowing MD5 certificates in 2012, it would make as much sense.
    - revelation 10y ago
      The CA did the equivalent of purposefully putting their hand into a garbage disposal unit. You're telling me we should not reconsider them as a root CA because the unit didn't say "don't put your hand into this". Honestly, I'm not sure how you plan to argue your way around a situation where I ended up with a rogue "mail.google.com" certificate accepted by my browser. That wasn't in the rules?! The CA wasn't clear on the policy for that?

CAs have been caught issuing CA=YES certificates and Mozilla have done nothing. https://bugzilla.mozilla.org/show_bug.cgi?id=724929 https://bugzilla.mozilla.org/show_bug.cgi?id=724929 WONTFIX

jasonjei 10y ago

I think Chinese CAs are also special cases. If American browser vendors remove a Chinese CA like WoSign, there is the possibility a fork distribution will replace Mozilla in China by inclusion of these certificates. I think it would take the cooperation of the Big 4 browser/OS vendors to remove a CA, and the Chinese market often responds by creating its own internal distribution.

deleted 10y ago
[deleted]
amluto 10y ago
But Firefox probably could name-constrain WoSign to .cn. Firefox could probably also name-constrain all StartCom-issued certificates after some cut-off-date to .cn or just ban new StartCom-issued certificates entirely.
- richardwhiuk 10y ago
  Banning due to cut-off dates is difficult when the CA has been shown to back-date certificates.
- tptacek 10y ago
  Reprising a previous comment about this suggestion: This is one of those ideas that sounds like common sense when you hear or think about it the first time, but falls apart on scrutiny. Ryan Sleevi has done a much better job picking it apart than I can here, but among the numerous problems with it: * The most important TLDs are transnational, and their trust hierarchies back into corporations (corporations, I will cheerfully and without irony point out, who are subject to the whims of the FVEY IC). * It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism. * It consigns residents of countries with oppressive governments to total control by their governments, while at the same time making usage constraints based on those TLDs (such as local mandates to use services whose names end in .XX for XX in $bad_countries) much more powerful. * It further promotes the idea that security should somehow be tied to the DNS, despite the fact that the DNS is itself not transparently managed, and is often managed at odds with the interests of Internet users as a whole. * By factionalizing Internet trust, it harms interoperability and also makes it harder to introduce further constraints into the certificate system by essentially declaring up front that we're conceding Internet trust policy to individual nations. * It greatly complicates the security stories of companies that have adopted vanity domain names in random countries, which, whatever you think of those companies (koff! Pinboard), is an unforced error. Of all the things we can spend time on to improve Internet security, this is not one of the better ones.
  - idlewords 10y ago
    Let's see if you still think my .IN "vanity" domain is a mistake come November 9. I'm putting my chips on the world's biggest democracy!
    - tptacek 10y ago
      HE'S NOT GOING TO WIN EVERYTHING WILL BE FINE SHUT UP
      - trump4president 10y ago
        I will win and put you behind a wall that you will pay for!
  - wtbob 10y ago
    > The most important TLDs are transnational, and their trust hierarchies back into corporations (corporations, I will cheerfully and without irony point out, who are subject to the whims of the FVEY IC). Are they? I always thought that .com, .edu, .net et al. are American. I suppose one could argue that .eu is transnational, although the EU are trying very hard to invent their own postmodern nation. > It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism. It's not really jingoism, although it might be nationalism. And is it even nationalism, when each nation-state makes its corporate decisions in a manner which is acceptable to the members of said state? > It consigns residents of countries with oppressive governments to total control by their governments … which they already are under, so it doesn't make anything worse. And they are, of course, free to revolt, as oppressed peoples have done throughout history, sometimes succeeding and sometimes failing. > By factionalizing Internet trust You say factionalising, I say federating. It doesn't make any sense to me for a corporation in Canada to certify the identity of a site in Iran for a resident of Guinea-Bissau, which is the current situation. Federation seems to me to be the only solution capable of scaling to a world of billions. > It greatly complicates the security stories of companies that have adopted vanity domain names in random countries I think the unforced error was placing their identities in the hands of foreign states. And, of course, with domain-level validation, their security is already in the hands of those states.
- cpeterso 10y ago
  WoSign issues certificates for domains outside .cn.
niftich 10y ago
This is PKI at its worst; when the incentives of a particular user's trust delegate (the browser) don't align with that of the user.
- tptacek 10y ago
  ... which is to say, it describes all tree-structured PKIs. (I agree).

agwa 10y ago

That was the first and only CA to be excused for that. When ANSSI did it, they got name-constrained to French TLDs only: https://bugzilla.mozilla.org/show_bug.cgi?id=952572 https://bugzilla.mozilla.org/show_bug.cgi?id=952572 When CNNIC did it, they were distrusted: https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/ https://blog.mozilla.org/security/2015/04/02/distrusting-new...

revelation 10y ago
Right, because the security of the CA system is a game of probability. No, one bad apple spoils the haul.
- agwa 10y ago
  Probability has nothing to do with it. Trustwave was excused because what they were doing was not expressly prohibited at the time and other CAs were probably doing the same thing. Trustwave proactively came forward about what they had done. They shouldn't have been the only ones to be distrusted as a result. CAs are not going to be excused for this again, as CNNIC and ANNSI show.
  - revelation 10y ago
    It was not expressly prohibited to have third parties sign a certificate for google.com? Security isn't some taxation game where you find a loophole for your weekend car in the rules, it's about outcomes.
    - tptacek 10y ago
      No, it wasn't. That's because the certificates we're talking about were intended to substitute for Google's. They were for enterprise networks, some of them with legal requirements to monitor outgoing traffic (Google Mail in particular is a big problem at regulated financial firms.) The CA=YES certificates were housed in DLP and proxy appliances that ran only on the borders of their own networks. Enterprises wanted these certificates because the alternative to them is installing additional root certificates on everyone's desktop machines, which is a logistical pain. I'm not excusing that CA transaction. Issuing CA=YES certificates as a convenience for enterprise security teams is terribly irresponsible, and never should have been allowed. But, at the the the Trustwave thing happened, it was not expressly black-letter against the rules, and so Trustwave didn't get the CA death penalty for it. They would, supposedly, if they did it again.

geofft 10y ago

IIRC, that happened when it was not totally clear that a CA shouldn't be doing that. That incident made it clear that such a thing was in fact prohibited by Mozilla policy, and the CA in question revoked the cert. If it happens again, I would expect the CA (regardless of size) to be revoked—but at the same time, I would expect the big CAs to know they shouldn't even think of it now, which apparently they didn't know in 2012. "WONTFIX" is the technical status of the Bugzilla bug, because there wasn't a code change, but it's clear that Mozilla took a policy action: > I have posted a draft CA Communication in the mozilla.dev.security.policy forum for review/discussion. My intent is to make it clear that this type of behavior will not be tolerated for subCAs chaining to roots in NSS, give all CAs fair warning and a grace period, and state the consequences if such behavior is found after that grace period. There is also an action item for CAs to update their CP/CPS to make it clear that they will not issue subCAs for this purpose. (That also happened when the browser world was less good at dealing with bad CAs, in general)

revelation 10y ago
Incredulous. This is a CA signing away their business and you make it sound like some kind of policy misunderstanding. No, that can not stand.
- geofft 10y ago
  It absolutely was a policy misunderstanding in 2012. It is no longer a misunderstanding, since it is now abundantly clear to CAs that they can't do that. It no longer stands. As far as CA policy goes, 2012 was the very distant past. You might as well accuse Mozilla of poor judgment for allowing MD5 certificates in 2012, it would make as much sense.
  - revelation 10y ago
    The CA did the equivalent of purposefully putting their hand into a garbage disposal unit. You're telling me we should not reconsider them as a root CA because the unit didn't say "don't put your hand into this". Honestly, I'm not sure how you plan to argue your way around a situation where I ended up with a rogue "mail.google.com" certificate accepted by my browser. That wasn't in the rules?! The CA wasn't clear on the policy for that?