Forgot your password?
typodupeerror
The Internet Networking Security IT

Four CAs Have Been Compromised Since June 87

Posted by Soulskill
from the four-whole-californias-wow dept.
Trailrunner7 writes "The EFF, through the use of its SSL Observatory, has taken a look at the data from certificate revocation lists for SSL certificates in recent months, and found that there were four separate CAs compromised in the last four months. The only widely known CA compromise since June is the attack on DigiNotar this summer that completely compromised that company's CA infrastructure and eventually led to it being shut down. All of the major browser vendors were forced to revoke their trust in the DigiNotar root certificates and the attacker who claimed credit for the attack said that he also had compromised several other CAs. There are apparently three other CAs that have discovered compromises since June, but have not made them public."
This discussion has been archived. No new comments can be posted.

Four CAs Have Been Compromised Since June

Comments Filter:
  • by Anonymous Coward

    There are apparently three other CAs that have discovered compromises since June, but have not made them public.

    That certainly strengthens my trust in the SSL certificate system.

    • System is broken. De-centralize website security NOW!

      • Another CA system is broken article?

        Consider an alternative model based on notaries:

        Other resources of note: Moxie Marlinspike's article on "trust agility" [thoughtcrime.org], his Black Hat Conference talk on this topic [youtube.com].

      • I actually agree. Same with DNS.

        However, there is a problem with reputation. How do you know that the name, or cert you have from someone is actually from the real person and not counterfeit?

        We've tried central authorities. You have all seen the results. It mostly works, as long as you trust the central authority. How do you make a completely distributed system work? It requires some sort of reputation about people and companies you have never been in contact with.

        Note, we haven't solved this problem in rea

        • by Anonymous Coward

          I actually agree. Same with DNS.

          However, there is a problem with reputation. How do you know that the name, or cert you have from someone is actually from the real person and not counterfeit?

          Decentralize it! Open it! Fixes everything!

          We've tried central authorities. You have all seen the results. It mostly works, as long as you trust the central authority. How do you make a completely distributed system work? It requires some sort of reputation about people and companies you have never been in contact with.

          You don't MAKE it do anything! What part of "decentralize it" don't you understand? It's magical! Wave a magic decentralize wand around and crowdsourcing will solve everything! They're all reliable! There's no risk of some anonymous trolls coming by to piss everyone off and spoil the trust of the system!

          • by DavidTC (10147)

            Uh, there is a trivial way to decentralize SSL now that we've got signed DNSSEC working. Simply put the SSL fingerprint (Or even the entire public key) in a DNS record, which is then, along with the rest of the DNS records, signed by the DNS server.

            Look, it is magic, and just as secure as before. (Because, frankly, if you have access enough to their DNS registrar to alter records, you can secretly point their mail at you long enough to grab a signed SSL key.)

            This puts 'I can prove I own this domain name'

            • Parent post hits nail squarely on head. Just because Random Hopeless CA X is still in a browser's trusted root CA list, should not mean that they can issue certs against my domain that anyone should trust. Placing signed cert public key fingerprints (or even the public key fingerprint of the root CA that actually issues your cert, if you really trust that CA) would make it much harder for an attacker to compromise a well-run, high-value web site (such as gmail.com or a banking web site).

              Google did this u

              • by DavidTC (10147)

                I find the way it works now completely absurd.

                It's like if someone wanted to be able to prove they owned a car, they had to print up a piece of paper that said they owned it, and then go to a random 'Car Authorities' and have them stamp it.. The CA would then call up the DNS, I mean the DMV, ask for that car owner's mailing address, and mail the paper to them.

                Occasionally, someone forges a stamp, or slips an extra stamp into the 'list of acceptable stamps' that people check again, or sneaks into a CA at

        • by jd (1658) <imipak&yahoo,com> on Friday October 28, 2011 @07:22PM (#37875186) Homepage Journal

          This is something that has deteriorated over time. I won't say the original cert system was perfect (there were flaws you could drive a 40 tonne truck through) but Grade I certification required significant documentation proving identity plus some form of actual (ie: non-written) contact. That was not a bad idea, the problem was they also offered Grade III certification (a note saying "it woz me" on a napkin) or even grade IV (the request sufficed as proof it woz you) and corporations naturally gravitated towards the cheaper options which you can fly an Airbus 400 through with enough space for 40 tonne trucks on either side.

          The problem was that you still had to trust the CA and this is a major frailty in the CA system. Being assured that the applicant is who they say they are is a major thing - Verisign issued hackers with a signed Microsoft key at one point, because they were asked to in a fax, and DNS registrars are notorious for complying with bogus transfer requests - but it isn't everything. If the CA is compromised, then you have major problems even if all the officially distributed keys are legit.

          Obviously, a Grade I cert system helps to some extent as requiring a thorough screening of applications means you aren't doing live cert distribution which in turn means the master key need not be on any online computer whatsoever. If the master key is behind a sneakernetwall, then hackers will have a harder time signing anything with it. (A sneakernetwall differs from an airwall in the level of competence of those moving stuff from one machine to another.) Obviously, given that eCommerce security holes repeatedly demonstrate corporations can't even put sensitive data behind a meager firewall and the VA is forever losing unencrypted laptops, there's a big difference between "need not" and "is not".

          A way to side-step the issue - to a degree only - would be to require that keys be counter-signed by at least one other CA. It is less likely that two CAs have been cracked by the same person, after all. Or, well, it would be if it weren't for the fact that it probably WAS the same person who broke into all four CAs and there's been an alleged confession that the person did break into two. That person would have been able to counter-sign a key with another CA's master key and since these were the cheapo kind of CAs that probably would indeed keep the master key on an online computer even if they needn't or legally shouldn't, a "Web of CA Trust" is not enough to be 0.45 bullet-proof but is probably 0.22 bullet-proof. The current system apparently falls over if you show it a picture of a bullet.

          IPv6 may help, since violations of strict hierarchical addressing are not only commonplace in IPv4 but actually a necessity due to the limitations of the addressing scheme. In IPv6, routing relies heavily on sub-domains having IP addresses with a prefix equal to the prefix of the domain plus two byte identifier unique within that domain. This means you can identify where things are. Yes, there are privacy issues for personal machines and that's been a major complaint against IPv6, but it means that you've a lot more confidence that a server is in roughly the right place. If you then add DNSSEC or any of the other DNS locking schemes out there, OR mandate an IPSec mode using certificates in a way that would offer equal guarantees that the server is who it says it is, it would help but you're starting to get into the diminishing returns then.

          Of course, this might be the wrong approach entirely. This is trying to find a technical solution to what is ultimately a social problem. Social solutions are usually far better for such things. One social solution would be to regulate cross-border traffic such that eCommerce vendors (CAs included) that wish to conduct cross-border traffic (whether into the country or between boundaries within it) have to publicly declare all actual security breaches and may be held 100% liable for any loss due to unreported breaches. That's definitely not going to sit well with those

          • One social solution would be to regulate cross-border traffic such that eCommerce vendors (CAs included) that wish to conduct cross-border traffic (whether into the country or between boundaries within it)...

            A much better social solution would be to tear down the borders. They're only there to perpetuate the slave trade anyway. Making them more restrictive is exactly the opposite of what is needed.

            • by jd (1658)

              Ah yes. I can just see the US assigning full sovereign authority to the UN, which is what tearing down all the borders would ultimately imply. One world government, a new world order and all that. Half the country would be in flames and the other half would claim it should be entitled to be.

              I don't dispute that borders are a problem, I certainly don't dispute that insular pockets take themselves far too seriously, but that's never going to work as a solution. Even if you didn't take it to the logical limits

    • For the paranoid/cautious: there exist extensions to FF which monitor suspicious changes to certificates (i.e., possible MITM attacks). I use Certificate Patrol [psyced.org].

  • by SydShamino (547793) on Friday October 28, 2011 @04:17PM (#37873238)

    Short of the companies wanting to the good/legal thing, how do you get them to make it public if it quickly puts them out of business? This is the same problem as with any security breach, except aggravated because the CAs basically have just five "customers" (the five major browsers), all of which compete in the realm of being the "safest" and so all five have to pull the root certificate for anyone who announces a problem.

    • by Eponymous Coward (6097) on Friday October 28, 2011 @04:34PM (#37873430)

      Almost every decision Diginotar made around the breach, was a bad one. Other CA's have had breaches and made responsible disclosures and they are still around. That doesn't mean there are zero consequences (nor should there be), but responsible behavior goes a long way in convincing their 5 customers that they are still worth trusting.

      • by hairyfeet (841228)

        Exactly! Mistakes get made folks, nobody is perfect, but the way to tell a good company from a bad company is how they react when the poo hits the fan which is why I still use Comodo products even though they did have a breach last year. Once they found out they had a compromise they were updating Comodo Dragon browser to revoke those keys as well as sending updates to the other browser teams, they even got MSFT to release an out of cycle patch for windows that revoked those keys.

        So it all comes down to h

    • by Anonymous Coward

      DigiNotar didn't make anything public. They tried to hide it, and that's what killed them. In fact, DigiNotar claimed nothing was wrong even on the day the Dutch government pulled their privilege to generate certificates to communicate with various government offices. I have witnessed this first hand because I work for a company that relied on DigiNotar's certificates (not by our choice).

      • by shentino (1139071)

        And that's what killed them.

        The big bad government had to step in.

        Business will ALWAYS misbehave unless it is watched.

    • by msauve (701917)
      Much of the reason Diginotar is out of business is precisely because they weren't timely, upfront and open about the issue. They delayed any notification until after it was known by other means. They understated the extent of the issue, and AFAIK, never did admit to the full scale of the compromise. Quite simply, their own actions showed they could not be trusted.

      That's why other CAs should have learned from that event, and should quickly be public and open about any compromises they may discover.

      Accordin
      • by St.Creed (853824)

        Much of the reason Diginotar is out of business is precisely because they weren't timely, upfront and open about the issue. They delayed any notification until after it was known by other means. They understated the extent of the issue, and AFAIK, never did admit to the full scale of the compromise. Quite simply, their own actions showed they could not be trusted.

        That's why other CAs should have learned from that event, and should quickly be public and open about any compromises they may discover.

        Also, the resulting investigation uncovered a gigantic mess. They built a castle, locked the gates, had it certified, then made huge holes in the walls because the gates were delaying the traffic... they didn't understand security at all and that was the final straw, IMO.

    • by sjames (1099) on Friday October 28, 2011 @07:45PM (#37875382) Homepage

      Is Comodo out of business? They are not, because they disclosed their compromise responsibly and took the necessary steps to correct their failure.

      Diginotar swept it under the rug for as long as they could, and in the end said themselves that their audit trails were so poor there was no choice but to remove their root cert.

    • Making it public doesn't put you out of business. Watch the recent events in the certificate blunders and you'll notice that CAs who went public had worries, but could rather easily recover. Issuing new certs is fairly easy.

      DigiNotar went under exactly for NOT going public and having any trace of trust eroded due to it.

  • Useless (Score:4, Insightful)

    by OverlordQ (264228) on Friday October 28, 2011 @04:19PM (#37873258) Journal

    This post is useless without naming them

    • At least it's useful for us to know that SSL has serious issues....

      • wow... next thing you know we're going to learn security by obscurity is not 100% effective, facebook and google may lead to concerns for privacy, and some virus's might not be detected by norton antivirus... Shocking.
    • Re:Useless (Score:5, Insightful)

      by Fished (574624) <amphigory@@@gmail...com> on Friday October 28, 2011 @04:37PM (#37873464)
      The data for the study came from x.509 certificate revocations. Do you really want to punish the CAs that did the right thing and filled out the certificate revocation correctly? That will just encourage fraud.
    • Agreed. Kind of like Fox News...
    • by Anonymous Coward

      Delete ALL certificates in your browsers.
      Then only add them, if you PERSONALLY trust them because you have checked them. Or at least have a more trustworthy third party that trusts them than "$browserMaker.randomResponsiblePerson".

      The concept is rotten at its core, as there is no such thing as a global "authority". It's the opposite of natural human webs of trust.

    • by Vellmont (569020)


      This post is useless without naming them

      I'd say the exact opposite is true. It's FAR more useful to NOT name the CAs. Why? It points out that the CA system is entirely broken. If the CAs had been named, the compulsion would be to simply point at the 4 "bad guys", hope they go out of business, and everything is back to "business as usual". Then wait for the next group of CAs to get own3d. Rinse, repeat. In short, it doesn't matter which 4 were hacked, because the problem isn't bad apples, the problem

      • by jd (1658)

        You are entirely correct - rot is never confined to the "bad apples" that you spot - and the spreadsheet only shows the "bad apples" that actually sent messages saying that they were bad. It says nothing about CAs who simply revoked individual certificates that they know were unauthorized when it was a master key that was compromised. And you know that's bound to have happened. The disparity between bogus certs and compromised CAs was too great. Even there, you know that not all bogus certs get revoked, so

    • We need some sort of wiki for exposing flaws and hidden information that should be public. It'd be handy to see what secrets governments held. Also banking institutes. And it should be run in such a way that it doesn't make a rock star of the person running it while only actually leaking a few things. Maybe someone should get around to that someday...

      Seriously, fuckedcompany had more corporate leaks than wikileaks ever has. Too bad pud sold out (Can't blame him for making money but it's a shame it's gone)

  • 2. those that remain, put them under very heavy regulation, that they fund

    3. anyone who wants to open a new CA must jump through a ridiculous number of hoops

    the CAs are just too important to leave to the "hey man, the market takes care of itself" stupidity

    • by MobyDisk (75490)

      I think we need to do the opposite - have thousands of CAs. What we have seen from this is that putting power in the hands of a small specially designated group is very risky. A public-key system can't rely on a hierarchy where a few organizations can bring down the entire web of trust.

      • by medv4380 (1604309)
        If even 1 of the thousand gets completely compromised and doesn't tell anyone you're in the same boat as having only a few organizations. The difference is the number of opportunities for it to occur. A better option would be to get rid of the system entirely but coming up with a viable replacement seems to be still in the air.
      • The CA architecture as it is used in web browsers is only as strong as its weakest link. It only takes one compromised CA to make the whole system worthless. Having thousands of CAs would make the problem significantly worse.

        • by MobyDisk (75490)

          If one CA is compromised, then you revoke the certificates generated by that authority and the rest of the system remains safe. The way it is now, each authority is so big they there is hesitation to revoke the certificates because so many sites then have invalid certificates.

    • by TubeSteak (669689)

      I don't have a problem with turning the CAs into a regulated utility....
      BUT, for that to work it would have to be everywhere/everyone at once,
      including internationally, and that never happens in the real world.

      • I don't have a problem with turning the CAs into a regulated utility....

        Regulated by who?

      • by shentino (1139071)

        Especially when you have to deal with other nation-states that may well have a vested interest in playing nice just to get an opportunity to stab you in the back.

    • by shentino (1139071)

      The problem with the CA market is that the hierarchial nature stifles competition. The guy at the top of the chain has pretty much omnipotent power and is effectively an oligopolist or worse a monopoly. His ability to say to his inferiors "see that X is dropped or *I* will drop *you*" is a very large club that can and will be used, and even if it isn't, it being possible is enough of a threat that often those lower in the chain dare not even think of defying their will. So the market of CAs is really the

    • ...put them under very heavy regulation...

      Yes, let's hand that over to the DHS

      • He said regulation, not circle-jerk security theater. We got enough of that in the CA business already.

  • There are apparently three other CAs that have discovered compromises since June, but have not made them public.

    I don't know how CRL's work, but if you have a list of certs that were revoked, can't you tell who revoked them? Doesn't the revoking CA have to sign the revocation request? Or do the researchers know who they are, but they chose to not make them public?

  • This is why I don't trust Certificates I haven't generated myself. In fact my prof for one of my security classes (I'm in Computer Security and Investigations at Fleming College) actually told us that untrusted certificate situations are more trustworthy, as the majority of attackers will go about getting a certificate through fraudulent means to avoid the scary pop-up window.

    • He is right. But only in rather specific circumstances, and only due to the problems CAs have.

      There's nothing more trustworthy than an "untrusted" certificate if, and only if, truster and trustee have some kind of preexisting relationship. But only as long as this becomes "common knowledge" and everyone does it, because then suddenly it becomes very interesting for an attacker to issue "untrusted" certs, since it's heaps easier than forging one and he can use the reliance of people on those "untrusted" cert

  • Put them all out of business and lets work on the actual issues. Browsers should be fixed to treat self signed certificates like normal encrypted channels and not viruses and there is a need for a new form of distributed authentication procedure that doesn't depend on a signing authority.

  • by Anonymous Coward

    While we do it almost daily in our lives, what use do we really have for CA's? They're simply not trustworthy - not by technical skills, and sure as hell not by trustworthiness; CA's willingly co-operate with intelligence agencies, for example.

    Wouldn't it be much better that we re-establish trust as a two party concept? For example, in order to make money transactions via bank, I would first go to a bank's website, my browser would tell me I'm being offered the bank's public key or similar, and I would then

    • by grahammm (9083) *

      I wonder how may bank telephone helplines for on-line banking could tell a caller the fingerprint of, or even which CA issued, the certificate for their on-line banking service. I suspect that not many could.

  • It's shit like this which makes me wish I'd picked another career. Plumbers aren't held liable or responsible if a specific fitting they installed is found to be defective or prone to corrosion; electricians aren't considered idiots for installing something which, at the fault of others, causes power failure to their TV.

    Hell, even the dipshit developers are regarded with higher esteem than IT.

  • Why the hell would people pay for a CA from a signer like VeriSign or Comodo when both of those corporations retain the rights to the security certificates issued to you in the first place. It is far easier to employ your very own CA and remove both of these signing authorities from the picture entirely. After all lets face it if your not sharing your SSL keys with the entire world, then it really is a lot harder for people who should not have a copy of them gaining one.
    • I've been using my own PKI for about a year now.. Capable of spawning RSA+SHA512@4068bit how is an attacker going to steal a copy of my CA? It's mine, so therefore you cant steal what I don't share!
    • The CAs never see the private key material. When you apply for a certificate, you generate the private key and a certificate signing request (CSR). It's the CSR which gets sent to the CA to sign, not the private key. All the CA has a copy of is the CSR and certificate, which is public knowledge anyway.
      • Yes and I can sign my own CSR as well.. So that removes the CA from the picture in it's entirety!
        • Thats what I mean by become your own Certificate Authority.. Once you can create all the certificate signing requests, manufacture the certificates, sign the certificates, enroll them as PKS1,2,3,4,5,6,7,8,9,10,11,12 then you are truly laughing and giving two fingers to any other third party who presumes to sell you there SSL CA solution. CSR, CRL, SCEP, XPI, Attribute Cert... The list goes on and on... VeriSign & Comodo have had their day... Time for them to move out of the way...
          • Would you like me to draft you a signed CA by me with 2048bit Data Encipherment complete with a revocation Certificate, how long would you like it to last as an Server SSL CA? Is until the year 3000 long enough!?!
  • It's discussed here [freedom-to-tinker.com].

    Basically, with DNSSEC, DNS cannot be tampered with. All you have to is have the DNS then itself provide the cert [faqs.org], which the registrar then signs.

    Basically, instead of having to send a CA our public key, and having them sign it and email it back, we just use the existing fact that, under DNSSEC, DNS records are signed, and stick so we just our public key in there. And unsigned keys can be checked there. Actually, it might be smart to have a specific mark on those keys, saying 'Check ag

    • by psydeshow (154300)

      Yes, let's please use DNSSEC so that our domain registrar becomes our effective CA. I'm not kidding. It would simplify things enormously, and greatly improve security, especially for high-risk domains.

      After all, I can go to any corrupt or government-operated CA and get a certificate for Google.com. But in order to to spoof DNSSEC I need to compromise Google's specific registrar, who has a very strong business incentive to not sign my fake google.com zone. The bigger the domain, the bigger the incentive to p

      • by DavidTC (10147)

        And while the registrar would 'sign' the keys, it wouldn't be a process like currently works. No one needs to send anything in and get it emailed back. DNSSEC is supposed to be completely automatic. And the internet is implementing DNSSEC anyway, because of other security issues.

        So once that's in place, you would just log into your registrar and paste in a copy of your public key into the host management area, or you'd point BIND at a copy of your public key, or whatever. That's it. The key actually used b

You can do this in a number of ways. IBM chose to do all of them. Why do you find that funny? -- D. Taylor, Computer Science 350

Working...