Forgot your password?
typodupeerror
Mozilla Security The Internet IT Technology

Mozilla Asks All CAs To Audit Security Systems 77

Posted by timothy
from the security-to-electronics-for-an-aisle-sweep dept.
Trailrunner7 writes "Already having revoked trust in all of the root certificates issued by DigiNotar, Mozilla is taking steps to avoid having to repeat that process with any other certificate authority trusted by Firefox, asking all of the CAs involved in the root program to conduct audits of their PKIs and verify that two-factor authentication and other safeguards are in place to protect against the issuance of rogue certificates."
This discussion has been archived. No new comments can be posted.

Mozilla Asks All CAs To Audit Security Systems

Comments Filter:
  • by Anonymous Coward

    Please... at least put the CA private keys in HSMs so there is an audit trail if everything else gets haxxored around.

  • by swan5566 (1771176) on Thursday September 08, 2011 @04:43PM (#37344922)
    This should be done on a regular basis anyway, and that by a third party.
    • My software company was in line to provide signature validation services for the State of California. Although we didn't land the contract, finding out what it took to become a legally recognized CA for California was part of the process. California (and by extension, most governments) requires a SAS70 audit. Performed once, and then re-performed annually. The audit itself cost about $25,000, we estimated the actual cost of compliance at $250,000.

      That's an approximation of what it costs to become a legally

  • by dremspider (562073) on Thursday September 08, 2011 @04:46PM (#37344970)
    If you ask nicely enough maybe they will do something about all their problems. What needs to happen is Mozilla needs to get with Microsoft, Chrome, Apple etc and say unless you submit yourself to an INDEPENDENT audit you will be revoked from our default trusted root certs. SSL has been destroyed, not because of protocol problems but because of the companies running the show. It was a race to the bottom from the beginning. Who could provide the cheapest service and make the most profit off of it. This model doesn't mesh well with Security and never will. Once one company operates their systems cheaply, everyone else must follow so as to maintain low prices.
    • by Anonymous Coward

      Who could provide the cheapest service and make the most profit off of it. This model doesn't mesh well with Security and never will. Once one company operates their systems cheaply, everyone else must follow so as to maintain low prices.

      Security does not need to be expensive to be good.
      But these companies were not in business to provide security services.

      • by Anonymous Coward

        Security requires attention. Attention requires man-hours. Man-hours cost money. Providing something without caring about security will always, in the very shortest term, be cheaper than providing it securely. In the medium or long term, that can change dramatically, of course.

        • by nedlohs (1335013) on Thursday September 08, 2011 @07:20PM (#37346584)

          And in this particular domain even the customer doesn't care.

          Sure I could spend more of my time and money finding and using the CA with the best security practices. But when the cheap-n-nasty is hacked to generate (or just hands out due to their lack of checking) a cert for my domain to someone else that the CA I chose wasn't hacked is completely irrelevant. I've gained nothing by choosing the more secure provider.

          So of course you have a race to the bottom...

    • by StripedCow (776465) on Thursday September 08, 2011 @05:21PM (#37345320)

      ...unless you submit yourself to an INDEPENDENT audit you will be revoked from our default trusted root certs

      In the case of Diginotar, Price Waterhouse Coopers was doing the audits.

      • PWC were (are) the auditors for AIG and Bank of Ireland.

      • by Anonymous Coward
        If you've ever worked for a PWC audited company, you'll know it's an annual tick and flick job by a handful of graduates who will report up to someone senior who's likely still only shaving twice a week.
      • by guruevi (827432)

        PWC from my experience don't do real audits. They're more like an insurance company. They may send out a drone that knows nothing about what he's supposed to be checking but the gross of the money you pay them probably goes to a fund in case you have a breach and sue PWC.

        I think that may be true of a lot of other audit companies. There are few audit companies that actually do penetration testing etc.

        • by sr180 (700526)

          Lol. So true. A mate of mine worked for them. He had an accounting background on top of a CS degree. One week he would be providing consultant advice on naval ship building, the next week on running a national train system - despite having zero experience in either of these activities. To put it simply, the powers that be, needed consultants, and PWC kindly stepped in and took plenty of their money!

      • ...unless you submit yourself to an INDEPENDENT audit you will be revoked from our default trusted root certs

        In the case of Diginotar, Price Waterhouse Coopers was doing the audits.

        OK, so an independent audit by an auditor who hasn't been banned from the list of reliable auditors like PWC.

        Is Mozilla really serious about trust or not?

      • In the case of Diginotar, Price Waterhouse Coopers was doing the audits.

        A big, fancy, expensive firm that actually didn't do their job. What a shock.

    • by BZ (40346)

      DigiNotar is not exactly an example of race to the bottom on price... more like a monopoly jacking up prices.

    • by Eol1 (208982)

      The problem here is you need an outside audit which they won't agree to as it might introduce liability. An independent audit doesn't mean anything (I used to be an auditor) as the audit firm wants repeat business.

      • by tlhIngan (30335)

        The problem here is you need an outside audit which they won't agree to as it might introduce liability. An independent audit doesn't mean anything (I used to be an auditor) as the audit firm wants repeat business.

        Easy. Microsoft, Mozilla, Apple, Opera pay auditors to audio every CA on their list. Auditors report to this consortium with yea or nay. If it's nay, vendors don't include CA on list of approved root CAs.

        CAs that don't agree to independent audio - certificate not included.

        CAs that fail - certifica

        • by Rockoon (1252108)
          Google gets to sit out and reap the benefits of the auditing investment of the others?

          So we add Google to the list...

          One of the problems I see is that some of these folks have large varied reliance on these CA's (Microsoft, Apple, Google) while the others (Mozilla, Opera) only do browsers. It is far more difficult for Microsoft, Google, and Apple to start denying CA's for not "cooperating" because it directly effects their users (of their OS's) in difficult to swallow ways (software, drivers, and other
        • by DarkOx (621550)

          The trouble is if you start having the browser vendors adding and removing CAs all the time, you screw things up for the certificate purchaser. My site gets screwed because my CA fails and audit and the browser vendor consortium drops the root certificate for my CA. That kinda sucks.

          • by heypete (60671)

            Indeed, it does suck.

            Nevertheless, if the CA fails an audit, they *should* be removed (perhaps after a reasonable time to resolve the problem and get re-audited, if the problem is not too serious).

          • by grahamm (8844)

            That is a case of caveat emptor. The prospective purchaser of a certificate could use the 'quality' of the audit as one of the criteria used to choose the vendor.

        • Easy. Microsoft, Mozilla, Apple, Opera pay auditors to audio every CA on their list.

          Yeah indeed. I'm all for it. Indeed the current list of approved CAs is way too long!

    • What needs to happen is Mozilla needs to get with Microsoft, Chrome, Apple etc and say unless you submit yourself to an INDEPENDENT audit you will be revoked from our default trusted root certs.

      The recent "Too big to fail" CA == Bank comparision story was all too succinct a comparision, and this method won't work for the same reason an independent audit of the banks won't work. In short, most if not all CAs are likely security bankrupt.

      Investigation is likely to find that CAs are only one step above flight by night organisations, with slipshod practices, procedures and security at every possible level, from the main servers to the secretaries email inbox. Are you ready to deal with the fallout from such revelations?

      Are you ready to actually revoke security authentication from millions of sites across the internet? Are you ready to deal with every major browser throwing a blue screaming fit every time a user connects to a major web commerce login? Are you ready and able unclog a seized up system, signed up to by every major player on the internet, and which a substantial portion of the modern net itself now rests on?

      The major problem here is the browsers, and Mozilla's actions here--requesting the CAs to police themselves--are exactly analogous to how our international banking system was woefully mismanaged over the last decades. What Mozilla should be doing is moving away from reliance on the Certification Authority system altogether. It has failed. It has become dangerous to users and website. It must be replaced or abandoned.

      Removing the DEFCON 2 warnings for self signed certs will be the first step in the right direction. Until then, Mozilla is just continuing to be part of the problem.

      • by Anonymous Coward

        Moving away from the CA system as it exists? Absolutely!
        Moving away from the CA system entirely? Possibly, but not necessarily.

        There's 4 problems with the CA system:

        1. Weakest-link failure, i.e. compromising any CA gets you a valid cert for any site.
        2. Crappy security at some/most/all CAs
        3. Limited response to compromises, because browsers don't want to cut massive chunks of the web off -- exacerbated by browser competition, where the one who "breaks the internet" by revoking trust in a compromised CA means losing
      • by tokul (682258)

        Removing the DEFCON 2 warnings for self signed certs will be the first step in the right direction.

        SSL is not about encryption. It is also about trust.

        • Removing the DEFCON 2 warnings for self signed certs will be the first step in the right direction.

          SSL is not about encryption. It is also about trust.

          Please tell us how it is a better idea to trust an unsigned site at the other end of an unencrypted connection MORE than a self-signed site at the end of a SSL connection. If sites with self-signed certs trigger a warning on browsers, then every site served in the clear should as well. A good compromise would be not to display the lock icon for sites with self-signed certs.

        • by Ja'Achan (827610)
          CAs are about trust. SSL is about encryption.
      • Investigation is likely to find that CAs are only one step above flight by night organisations, with slipshod practices, procedures and security at every possible level, from the main servers to the secretaries email inbox. Are you ready to deal with the fallout from such revelations?

        Yes. I am.

        http://tech.slashdot.org/story/11/09/08/1454221/Moxie-Marlinspikes-Solution-To-the-SSL-CA-Problem [slashdot.org]

    • SSL has been destroyed, not because of protocol problems but because of the companies running the show.

      It's the authentication part of the whole scheme that's the issue. Don't conflate SSL with the CA system; they are parts used together in a complete scheme. "SSL" would continue to work if we switched the authentication component to another method like distributed views (notaries).

      • "SSL" would continue to work if we switched the authentication component to another method like distributed views (notaries).

        Correct. But it would stop to work (securely) if we switched off the authentication component altogether (as in "just use self-signed certs" without planning for any other means of authenticating them)

        • I agree with the accommodating interpretation given to dremspider's comment [slashdot.org], that the SSL we're focused on, web SSL, is practically destroyed by the failure of the CA system.

          However, I'm trying to be a little more discerning by pointing out that SSL is one component in security schemes, distinct from the scheme itself, whichever one we're talking about. In web, the security scheme fails if the CA system fails. SSL can still be successfully used in other schemes, as in email, SIP, and VPNs.

          Maybe we should

  • Good security practices are fine (and should be absolutely requisite for CAs), but do nothing to address the real problem with CAs, which is anchored trust. I hope that all of the browsers move to implement Convergence [convergence.io].
    • by Spad (470073)

      The problem with Convergence is, how does the average user know which notaries to trust? They have no way of establishing who is trustworthy and who isn't, which means that in all likelihood they'll end up with a "default" set of notaries. At that point, you're only marginally better off than you are right now with the CAs, in that several notaries would have to be compromised in order to "fool" everyone instead of just the one.

      • The fact that you can kick off some CA without breaking half of the internet is already much better than now. With convergence/perspectives websites aren't tied to single CAs like they are right now, so you get what they call "trust agility."

        Regardless of who manages the notaries list, it's a big plus.

        • by bhingque (1915000)
          Exactly so. Even if you decide to wait for your browser vendor to remove a notary from their trusted list before you stop trusting it, you'll find this happening enormously more often than browser vendors are removing CAs. You cannot remove a CA without breaking all of the sites that use that CA, while you can remove a notary without breaking anything.
      • by JamKot (2221500)
        For a mitm attack to succeed with Convergence, two notaries would have to collude. I think I'd pick one Microsoft notary and one Google notary and trust that they would never collude. Seriously though, has anyone poked any serious holes in the Convergence protocol yet? It sounds pretty solid to me.
        • For a mitm attack to succeed with Convergence, two notaries would have to collude.

          No, it would be enough if a MITM can insert itself into the path from those two notaries to the target web server, and feed both notaries the same fake cert. No funny business by the notaries themselves is required.

          ===> so we better need the agreement of much more than just 2 notaries...

          Even with a protocol needing all notaries to agree, a web server could be MITM'ed by its own ISP if it is single-homed (because paths from all notaries and visitors would go through that ISP). In order to prevent this,

      • Average users could simply subscribe to a list of notaries like most users do with the filter lists for Adblock Plus or IE9's Tracking Protection lists. Someone trustworthy who cares maintains the "EasyTrust" list that most users will subscribe to, and the community of knowledgeable geeks keeps an eye on that and cries foul if it gets taken over by a Sith lord or something.

        But hell, even if the default list is maintained by the browser vendor, it's still way better than and more agile in response to proble

      • The problem with Convergence is, how does the average user know which notaries to trust?

        How does the average user know which CA to trust?

        in that several notaries would have to be compromised in order to "fool" everyone instead of just the one.

        You can set the notary algorithm to be very aggressive. As in all (rather than just most) notaries need to agree before a site is deemed secure. The rogue notary will become very obvious (because it stops everybody going to any SSL website), and will be promptly removed from the browsers' lists of trusted notaries.

        ... which means that notary compromise can only lead to a successful DOS, but never to a successful MITM.

  • by roman_mir (125474) on Thursday September 08, 2011 @04:56PM (#37345104) Homepage Journal

    Who can trust a CA? Why would you trust a CA? How did a CA earn your trust?

    Mozilla, it's time to own up. This is a bunch of nonsense. Stop treating self signed certificates like cancer, provide a way to see the fingerprint clearly, don't bother with the 'lock' icon and start working on some real innovation - how to do trust by having distributed lists of fingerprints, signatures, whatever. Something that doesn't rely on a signing authority at all.

    You want to do real innovation instead of looking at hiding address bar from the users [pcworld.com]? Do this instead.

    • +11 on this.
    • It"s actually a quite delicate matter that will take a long time to be resolved.

      Therefore its only responsible to incite CA's to quintuple check their security measures. Web's SSL won't change overnight because some guy at Mozilla would code a super awesome alternative (although we'd still all wish that).

      IMO the best option would be to have something that does away with the "must pay premium to have a cert that browsers trust".
      Meanwhile, DNSSEC helps as well.

    • Re: (Score:2, Interesting)

      by elsurexiste (1758620)

      Man, you are a broken record. We already talked about this a few days ago, but you are stubborn. I talked nicely then, but you really should leave security to people who have a clue. My karma can take the flak, so I'll be caustic.

      Who can trust a CA? Why would you trust a CA? How did a CA earn your trust?

      You trust CAs because the server you are talking with, by itself, can't confirm nor deny it is who it says it is: you need a third party and you said it yourself a few lines below. You trust those CAs because it's an audit-only club, and the friggin' web browser's company checked i

      • You trust those CAs because it's an audit-only club, and the friggin' web browser's company checked it

        Actually, only newcomers to those lists get audited (such as Cacert.org). Older CAs (such as Comodo et al.) are considered "too big to fail" and are grandfathered in. And so are CAs trusted by competing browsers because "we can't start throwing up scary warnings on sites which do not cause a problem to our competitors.

        Let's suppose they even give me a fingerprint or signature or whatever... That means squat: a certificate from an impostor also has a fingerprint. With what/whom do I check it, then?

        Checking the fingerprint is the entire point. But you're right: the general populace, including helpdesks at banks and elsewhere is just so clueless that they aren't even able to read you a 40

    • by tokul (682258)

      Stop treating self signed certificates like cancer

      In other news AIDS does not exists, USA is most peaceful country in the world and there are no American tanks in Bagdad.

      Self signed certificates are cancer. Your fingerprinting ideas won't work cause they abolish automatic verification of trustfulness, disable warnings on possible insecure situation, decentralize site verification and make verification laborious process.

      You have to identify yourself to some authorities trusted by your browser. Stop brag

    • Stop treating self signed certificates like cancer, provide a way to see the fingerprint clearly,

      Good luck making use of that. Ever tried to call the helpdesk of a server to verify its fingerprint? I'm pretty sure my bank would need to escalate such a request all the way up to the CEO, and still not be able to confirm the fingerprint...

  • "Mozilla [...is...] asking all of the CAs involved in the root program to conduct audits of their PKIs and verify that two-factor authentication and other safeguards are in place to protect against the issuance of rogue certificates."

    This may be the first REAL change in the CAs' assessments of the risk versus reward of building and maintaining good layered security systems. Until this week, the idea of a breach leading to delisting and the demise of the organization was an abstract idea. Now it is concrete, which makes all the difference (even though it shouldn't).

    Perhaps some mid-level geek will finally, successfully make his case that the issuance process should be airgapped (or other similarly expensive measures).

    Unfortunately, we haven't yet seen a change in the economics of issuing a certificate without proper vetting of the requestor. Right now it costs the CA almost nothing to issue a single certificate to somebody who isn't actually who they say they are. And vetting is a real-world activity involving meat and paper, so the MBAs in charge will never put money behind real vetting... until the economics change, anyway.

  • by DarkFencer (260473) on Thursday September 08, 2011 @05:08PM (#37345206)

    It really is security theater now. I've had to get certs from various vendors for the .edu I work at. They need 'official' documents from 'someone important'. Like a letter on official looking letter head with a copy of a photo ID faxed to them. Yeah. Real secure. Lemme break out my copy of photoshop.

    How about at the very least the verifications some sites use to show that you control a domain? For example, the CA says that in order to verify 'somesystem.somewhere.com' we're going to need you to put this arbitrary string in a TXT record on your DNS server for that host.

    When setting up a domain on Google Apps or MS Live (or other places) they ask you to do this as one of the things to do to prove domain ownership. Yes - obviously if your DNS is owned this isn't a problem, but its a heck of a lot better than the process now.

    • And they the tend to be the cheaper ones [godaddy.com]. However these certs are probably more likely to be at risk from the sort of whole CA system compromises we have seen recently here. IE they are issued largely automatically by key issuing servers that are accepting input from random users and have connectivity to the internet.

      At least with the issuing methods with more human involvement there is more possibility (not guaranteed of course) of a process involving a physical air gap between the key issuing machines an
  • It mostly doesn't matter. First, the current failed CAs were audited and still failed. More to the point, the whole system is failure by design. Any CA can issue any cert for anything and there's not even a designed way to see that it's a dup.

    Second, no matter how good a CA's practices are and how thorough the audit, if their government comes in with a goon squad and says "issue this cert NOW", they will.

  • Sounds like a great fing idea. Payment systems have manditory controls. Health systems have manditory controls. Government systems have manditory controls. SCADA systems have defined controls. the CA system is so important, they clearly should be following some controls (NIST's are pretty good) and be demonstrating compliance as a prerequisite to having their certs included in browsers. Also, as painful as it is (and even though Moxie suggested it couldn't practically be done), the browsers should eit
    • As for CAs that don't comply, simply put all their certs in a bucket along with self certs. They can still be used, but your computer will warn you.
  • Hehe, for the first time Chrome warned me that slashdot wasn't trusted when I went here this morning.

Uncompensated overtime? Just Say No.

Working...