8 ms·

CA:WoSign Issues

123 points by danielsiders 10y ago

pg_is_a_butt 10y ago
the only issue seems to be mozilla not taking the appropriate step of revoking WoSign.
Analemma_ 10y ago
So, can I ask an awkward question? Realistically speaking, is there any chance that a large CA would ever actually be removed from Mozilla's store, no matter how severe their malfeasance? I started wondering this after they declined to remove StartSSL after the Heartbleed fiasco, and while I sort of understood the reasoning there in isolation, between that incident and this long list of WoSign violations, I'm really getting the sense that CA's are "too big to fail" and that the downsides of suddenly breaking huge parts of the internet on unsuspecting users mean that the threat of removing badly-behaving CA's is an empty one. What would a CA have to do to actually be removed, especially if they were to sign really huge sites?
- revelation 10y ago
  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.
  - 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?
- jlgaddis 10y ago
  https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar
  - Rafert 10y ago
    DigiNotar wasn't a large CA according to that link: "Although DigiNotar had been a general-purpose CA for several years, they still targeted the market for notaries and other professionals."
- geofft 10y ago
  Now that Certificate Transparency exists, it's possible to take two actions that are almost as serious as removing a CA from the store, but do not break existing websites: 1. Ask for a list of all issued certificates, get signed certificate timestamps (SCTs) for all of them, and require that all certs issued by the CA have working CT. This essentially prevents all further misissuance (or, at least, makes it very public). 2. If the CA is so bad at life that it doesn't know what certificates have been issued, require CT for all new certificates (trusting the self-stated signature date on the certificate), and have a sword hanging over their head if any evidence arises that the CA has backdated any certificates. Chrome did #2 for Symantec, and then (I believe) moved to #1, and Symantec is definitely a too-big-to-fail CA. https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c... https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=INFO3663 https://knowledge.symantec.com/support/ssl-certificates-supp... https://groups.google.com/a/chromium.org/d/msg/ct-policy/hNKxsHIO8gU/Tzag4Z_zBwAJ https://groups.google.com/a/chromium.org/d/msg/ct-policy/hNK... Of course, Mozilla needs to add support for CT for this approach to work.
  - ceejayoz 10y ago
    > A sword hanging over their head if any evidence arises that the CA has backdated any certificates. Doesn't that just bring us right back to "too-big-to-fail CA"?
    - drostie 10y ago
      It's slightly better because at that point presumably you've failed auditing standards for many browsers, not just one. We're talking about "you tried to deliberately compromise security and get away with it by deliberately lying to take advantage of the loophole we'd provided you." With proof of that level of malfeasance, especially if it's widespread for new certs, it is plausible that Chrome and Firefox will both remove your certs, with Edge or Safari possibly coming up quickly behind. Presumably all of this would be "we are publicly announcing that we are dropping this CA in a month" to allow graceful switching...
- jcranmer 10y ago
  What's happening at the moment is that Mozilla (and Google) are undertaking fact-finding to figure out how badly WoSign messed up and to explore possible penalties. Removing WoSign, or even actively distrusting the certificate, is certainly on the table. As others have pointed out, there are now more remedies available than merely pulling the CA. That said, when you read the email thread, it's abundantly clear that WoSign is not saying what they should be saying. The first response document is inadequate (although they're working on a second document in response to the extra incidents): it seems like WoSign is trying to say "we quickly fixed every instance brought up to us!" and they aren't understanding that said answer isn't good enough for such a serious breach of trust. The remedy at this point is likely to be at least as severe as forbidding any certificate with an issuedBefore of soon. Honestly, if you're a sysadmin using a WoSign cert, I would recommend immediately looking into obtaining a cert from another CA as a backup.
mtgx 10y ago
I'm starting to think that a service such as SSL Labs should also grade CAs (perhaps by looking through Certificate Transparency logs as well, once all CAs have to use them). Then if you use like a "C-rated" CA, your HTTPS score is also limited to B. A B-rate CA would limit your HTTPS score to A, and only an A-rated CA would allow you to get A+ on SSLabs. Something along those lines. I imagine rating the CAs would be quite a complex task, but they could start with the big ones first that own 80-90% of the market.
- Klathmon 10y ago
  For that to be useful, browser vendors would have to start showing something other than a binary "secure" "not secure" setup to the user along with some of that info. Also, it sounds like something that will be very easy to corrupt.
  - imglorp 10y ago
    Distribute hashes of certified claims via blockchain.
  - khc 10y ago
    the best hope is google itself doing it, since most users probably won't look at the secure vs secure-but-not-quite unless it's a scary warning page. Ranking websites lower though and the marketing departments will start calling.
  - jo909 10y ago
    SSL Labs is a tool mainly used by the website owners/administrators, not so much by end users (and if at all an end user will then complain to the owner about a low rating). Downgrading the rating because he used a "fishy" CA might motivate the website owner to switch to a CA with better standing. The bad CA will feel pressure to clear their standing.
azdle 10y ago
Does anyone know if it's possible to write a Firefox add-on that could warn you that the site you're connecting to uses one of these less trustworthy or esoteric CAs? I've looked through the APIs, but I don't see any hooks for that kind of info. EDIT: Now that I think about it, it must be possible, Certificate Patrol is looking at the cert info, I'll see how they do it.
- gkoberger 10y ago
  You could probably use the website URL + an API (such as https://www.ssllabs.com/projects/ssllabs-apis/ https://www.ssllabs.com/projects/ssllabs-apis/)? There might be a better way, though.
  - Retr0spectrum 10y ago
    If someone shady was MITMing your traffic, they could just block access to the API. If you wanted to do the checks before loading each URL, it would make things very slow.
- MrRadar 10y ago
  Since I don't browse Chinese websites I just distrusted the WoSign root and used the Red Jacket add-on[0] to distrust their intermediate certs (at least some of which are cross-signed by other trusted CAs). [0] https://addons.mozilla.org/en-US/firefox/addon/red-jacket/ https://addons.mozilla.org/en-US/firefox/addon/red-jacket/ (this is necessary since there's no built-in UI in Firefox to distrust intermediate certificates: https://bugzilla.mozilla.org/show_bug.cgi?id=585352 https://bugzilla.mozilla.org/show_bug.cgi?id=585352)
- nsgi 10y ago
  To some extent this would provide a false sense of security, as if the CA misissues a certificate it wouldn't stop it from being used to hijack your session with an iframe.
newman314 10y ago
While I've seen some scripts to "blackhole" so-called bad/suspicious CAs, I have yet to find something that cleans things across the board for different browsers. Apple's implementation of "Rootless" while useful for other things hasn't helped by denying the ability to remove certs unless one reboots into recovery and does "csrutil disable".
devy 10y ago
Where WoSign have demonstrated glaring incompetence and utter ignorance of security practices as an CA, I doubt these issues aren't violated at quite a few dozens of other CAs. These are good lessons for other CAs. To me, the ultimate question is this: if we are trusting CAs as the 3rd party entity in order to make PKI schemes work, then who's going to be auditing the "supposedly trustworthy" party?
- joepie91_ 10y ago
  I've at least started a list of CA incidents here, to try and make this a bit more transparent: https://git.cryto.net/joepie91/ca-incidents https://git.cryto.net/joepie91/ca-incidents Contributions are more than welcome.
themihai 10y ago
Hopefully one day we will replace CAs with something decentralized(i.e based on DNSSEC). CAs make sense only if you need an EV certificate.
- Panino 10y ago
  DNSSEC is not decentralized -- it follows a strict hierarchy from ICANN => TLDs (world governments) => you. DNS is distributed, not decentralized.
  - themihai 10y ago
    Right... but at least you cut off the CA from the scheme. You depend on ICANN -> TLD anyway.
drdaeman 10y ago
> For example, a cert where the owner validated "netwi.ru" was able to add "mx.idisk.su", an entirely different domain, without validating it. Now that's odd, because I know those two domains. I've even requested some certificates for them myself before (never had anything odd - I think I would've noticed if there was a way to add a domain without validation), but I left the company in January 2015. It was my coworker requesting that certificate, and I've just found - still have the access to the servers as I help them with small issues on rare occasions - that at the same date it was issued (Feb 26, 2015) he had most certainly got a validation file (idisk.su.html) and put it into idisk.su's static root. Webserver logs are, of course, long gone so can't really tell if it was actually accessed or not, but I think when I had requested certificates myself it was a wizard-style process where one got a file to download and the only next action was to validate it, no other way to proceed. I mean, at least he got the file and put it there, in a proper place. And it's also weird that the certificate in question (https://crt.sh/?id=29805560 https://crt.sh/?id=29805560) had included another idisk.su subdomain (mail.idisk.su) that wasn't marked as not validated in the report (https://www.wosign.com/report/wosign_incidents_report_09042016.pdf; https://www.wosign.com/report/wosign_incidents_report_090420... page 13). I don't doubt there was a severe bug. But this leaves me wondering whenever the analysis followed was really accurate (not saying it wasn't, but still sort of curious that it could be).

123 points by danielsiders 10y ago

the only issue seems to be mozilla not taking the appropriate step of revoking WoSign.

So, can I ask an awkward question? Realistically speaking, is there any chance that a large CA would ever actually be removed from Mozilla's store, no matter how severe their malfeasance? I started wondering this after they declined to remove StartSSL after the Heartbleed fiasco, and while I sort of understood the reasoning there in isolation, between that incident and this long list of WoSign violations, I'm really getting the sense that CA's are "too big to fail" and that the downsides of suddenly breaking huge parts of the internet on unsuspecting users mean that the threat of removing badly-behaving CA's is an empty one. What would a CA have to do to actually be removed, especially if they were to sign really huge sites?

revelation 10y ago
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.
- 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?
jlgaddis 10y ago
https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar
- Rafert 10y ago
  DigiNotar wasn't a large CA according to that link: "Although DigiNotar had been a general-purpose CA for several years, they still targeted the market for notaries and other professionals."
geofft 10y ago
Now that Certificate Transparency exists, it's possible to take two actions that are almost as serious as removing a CA from the store, but do not break existing websites: 1. Ask for a list of all issued certificates, get signed certificate timestamps (SCTs) for all of them, and require that all certs issued by the CA have working CT. This essentially prevents all further misissuance (or, at least, makes it very public). 2. If the CA is so bad at life that it doesn't know what certificates have been issued, require CT for all new certificates (trusting the self-stated signature date on the certificate), and have a sword hanging over their head if any evidence arises that the CA has backdated any certificates. Chrome did #2 for Symantec, and then (I believe) moved to #1, and Symantec is definitely a too-big-to-fail CA. https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c... https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=INFO3663 https://knowledge.symantec.com/support/ssl-certificates-supp... https://groups.google.com/a/chromium.org/d/msg/ct-policy/hNKxsHIO8gU/Tzag4Z_zBwAJ https://groups.google.com/a/chromium.org/d/msg/ct-policy/hNK... Of course, Mozilla needs to add support for CT for this approach to work.
- ceejayoz 10y ago
  > A sword hanging over their head if any evidence arises that the CA has backdated any certificates. Doesn't that just bring us right back to "too-big-to-fail CA"?
  - drostie 10y ago
    It's slightly better because at that point presumably you've failed auditing standards for many browsers, not just one. We're talking about "you tried to deliberately compromise security and get away with it by deliberately lying to take advantage of the loophole we'd provided you." With proof of that level of malfeasance, especially if it's widespread for new certs, it is plausible that Chrome and Firefox will both remove your certs, with Edge or Safari possibly coming up quickly behind. Presumably all of this would be "we are publicly announcing that we are dropping this CA in a month" to allow graceful switching...
jcranmer 10y ago
What's happening at the moment is that Mozilla (and Google) are undertaking fact-finding to figure out how badly WoSign messed up and to explore possible penalties. Removing WoSign, or even actively distrusting the certificate, is certainly on the table. As others have pointed out, there are now more remedies available than merely pulling the CA. That said, when you read the email thread, it's abundantly clear that WoSign is not saying what they should be saying. The first response document is inadequate (although they're working on a second document in response to the extra incidents): it seems like WoSign is trying to say "we quickly fixed every instance brought up to us!" and they aren't understanding that said answer isn't good enough for such a serious breach of trust. The remedy at this point is likely to be at least as severe as forbidding any certificate with an issuedBefore of soon. Honestly, if you're a sysadmin using a WoSign cert, I would recommend immediately looking into obtaining a cert from another CA as a backup.

mtgx 10y ago

I'm starting to think that a service such as SSL Labs should also grade CAs (perhaps by looking through Certificate Transparency logs as well, once all CAs have to use them). Then if you use like a "C-rated" CA, your HTTPS score is also limited to B. A B-rate CA would limit your HTTPS score to A, and only an A-rated CA would allow you to get A+ on SSLabs. Something along those lines. I imagine rating the CAs would be quite a complex task, but they could start with the big ones first that own 80-90% of the market.

Klathmon 10y ago
For that to be useful, browser vendors would have to start showing something other than a binary "secure" "not secure" setup to the user along with some of that info. Also, it sounds like something that will be very easy to corrupt.
- imglorp 10y ago
  Distribute hashes of certified claims via blockchain.
- khc 10y ago
  the best hope is google itself doing it, since most users probably won't look at the secure vs secure-but-not-quite unless it's a scary warning page. Ranking websites lower though and the marketing departments will start calling.
- jo909 10y ago
  SSL Labs is a tool mainly used by the website owners/administrators, not so much by end users (and if at all an end user will then complain to the owner about a low rating). Downgrading the rating because he used a "fishy" CA might motivate the website owner to switch to a CA with better standing. The bad CA will feel pressure to clear their standing.

azdle 10y ago

Does anyone know if it's possible to write a Firefox add-on that could warn you that the site you're connecting to uses one of these less trustworthy or esoteric CAs? I've looked through the APIs, but I don't see any hooks for that kind of info. EDIT: Now that I think about it, it must be possible, Certificate Patrol is looking at the cert info, I'll see how they do it.

gkoberger 10y ago
You could probably use the website URL + an API (such as https://www.ssllabs.com/projects/ssllabs-apis/ https://www.ssllabs.com/projects/ssllabs-apis/)? There might be a better way, though.
- Retr0spectrum 10y ago
  If someone shady was MITMing your traffic, they could just block access to the API. If you wanted to do the checks before loading each URL, it would make things very slow.
MrRadar 10y ago
Since I don't browse Chinese websites I just distrusted the WoSign root and used the Red Jacket add-on[0] to distrust their intermediate certs (at least some of which are cross-signed by other trusted CAs). [0] https://addons.mozilla.org/en-US/firefox/addon/red-jacket/ https://addons.mozilla.org/en-US/firefox/addon/red-jacket/ (this is necessary since there's no built-in UI in Firefox to distrust intermediate certificates: https://bugzilla.mozilla.org/show_bug.cgi?id=585352 https://bugzilla.mozilla.org/show_bug.cgi?id=585352)
nsgi 10y ago
To some extent this would provide a false sense of security, as if the CA misissues a certificate it wouldn't stop it from being used to hijack your session with an iframe.

newman314 10y ago

While I've seen some scripts to "blackhole" so-called bad/suspicious CAs, I have yet to find something that cleans things across the board for different browsers. Apple's implementation of "Rootless" while useful for other things hasn't helped by denying the ability to remove certs unless one reboots into recovery and does "csrutil disable".

devy 10y ago

Where WoSign have demonstrated glaring incompetence and utter ignorance of security practices as an CA, I doubt these issues aren't violated at quite a few dozens of other CAs. These are good lessons for other CAs. To me, the ultimate question is this: if we are trusting CAs as the 3rd party entity in order to make PKI schemes work, then who's going to be auditing the "supposedly trustworthy" party?

joepie91_ 10y ago
I've at least started a list of CA incidents here, to try and make this a bit more transparent: https://git.cryto.net/joepie91/ca-incidents https://git.cryto.net/joepie91/ca-incidents Contributions are more than welcome.

themihai 10y ago

Hopefully one day we will replace CAs with something decentralized(i.e based on DNSSEC). CAs make sense only if you need an EV certificate.

Panino 10y ago
DNSSEC is not decentralized -- it follows a strict hierarchy from ICANN => TLDs (world governments) => you. DNS is distributed, not decentralized.
- themihai 10y ago
  Right... but at least you cut off the CA from the scheme. You depend on ICANN -> TLD anyway.

drdaeman 10y ago

> For example, a cert where the owner validated "netwi.ru" was able to add "mx.idisk.su", an entirely different domain, without validating it. Now that's odd, because I know those two domains. I've even requested some certificates for them myself before (never had anything odd - I think I would've noticed if there was a way to add a domain without validation), but I left the company in January 2015. It was my coworker requesting that certificate, and I've just found - still have the access to the servers as I help them with small issues on rare occasions - that at the same date it was issued (Feb 26, 2015) he had most certainly got a validation file (idisk.su.html) and put it into idisk.su's static root. Webserver logs are, of course, long gone so can't really tell if it was actually accessed or not, but I think when I had requested certificates myself it was a wizard-style process where one got a file to download and the only next action was to validate it, no other way to proceed. I mean, at least he got the file and put it there, in a proper place. And it's also weird that the certificate in question (https://crt.sh/?id=29805560 https://crt.sh/?id=29805560) had included another idisk.su subdomain (mail.idisk.su) that wasn't marked as not validated in the report (https://www.wosign.com/report/wosign_incidents_report_09042016.pdf; https://www.wosign.com/report/wosign_incidents_report_090420... page 13). I don't doubt there was a severe bug. But this leaves me wondering whenever the analysis followed was really accurate (not saying it wasn't, but still sort of curious that it could be).