Four CAs Have Been Compromised Since June 87
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."
Hmm. (Score:1)
That certainly strengthens my trust in the SSL certificate system.
Re: (Score:1)
System is broken. De-centralize website security NOW!
obligatory references (Score:3)
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].
Yes, but the reputation problem hasn't been solved (Score:3)
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
Re: (Score:1)
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!
Re: (Score:2)
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'
Re: (Score:1)
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
Re: (Score:2)
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
Re:Yes, but the reputation problem hasn't been sol (Score:5, Insightful)
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
Re: (Score:1)
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.
Re: (Score:2)
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
Workaround (partial) (Score:2)
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].
Make Public = Out of Business? (Score:4, Interesting)
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.
Re:Make Public = Out of Business? (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:1)
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).
Re: (Score:3)
And that's what killed them.
The big bad government had to step in.
Business will ALWAYS misbehave unless it is watched.
Re: (Score:2)
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
Re: (Score:2)
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.
Re:Make Public = Out of Business? (Score:4, Insightful)
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.
Re: (Score:3)
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)
This post is useless without naming them
Re: (Score:3)
At least it's useful for us to know that SSL has serious issues....
Re: (Score:2)
Re:Useless (Score:5, Insightful)
Re: (Score:1)
Only one way, if you're serious about it: (Score:1)
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.
Re: (Score:2)
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
Re: (Score:2)
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
It'd be nice to have a wiki for secret info (Score:2)
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)
Who has nothing to hide? (Score:2)
You say this as if there is a significant number of people who fall into the category. Or as if it's a bad thing. Most people do have things to hide. Like a credit card number, for example.
Re: (Score:2)
If you got nothing to hide, you're an idiot. And while I'll assume you're not entirely serious in this post, allow me to use it as a soapbox against the whole "got nothing to hide" crowd out there.
Everyone has "something to hide". And it doesn't even have anything to do with the internet. Actually, as soon as you remove "teh Intarnets" from the equation, people start to understand that they do. Who can sensibly say that they have never answered "none of your business" to any questions they have ever been as
1. reduce the number of CAs to a handful (Score:1)
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
Re: (Score:2)
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.
Re: (Score:2)
You don't seem to understand the problem (Score:2)
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.
Re: (Score:1)
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.
Re: (Score:2)
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.
Re: (Score:2)
Regulated by who?
Re: (Score:2)
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.
Re: (Score:2)
The problem with "voting with your dollars" is not getting OUT voted by organizations whose interests run counter to your own.
You can shout with every decibel of your wealth, but it does no good if the 800 pound gorilla can drown you out just by whispering briefcases full of cash.
Re: (Score:2)
Free market works in a world of level headed, sensible and perfect human beings. But then we could as well switch to communism, it would work too.
Re: (Score:2)
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
Re: (Score:1)
...put them under very heavy regulation...
Yes, let's hand that over to the DHS
Re: (Score:2)
He said regulation, not circle-jerk security theater. We got enough of that in the CA business already.
Why aren't the compromised CA's known? (Score:2)
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?
Re: (Score:2)
You pretty much just have a Certificate Serial Number that has been revoked, with no other identifying information.
If you find the Certificate matching the CRL entry's Serial Number then you find the CA.
If the CRL is not signed, how do you know it came from the CA and not from a random hacker? Revoking CRL's from big name sites seems like it would be an attractive target. How is a CRL entry validated? How does a CRL make it to my browser?
The Wikipedia article just says that it's published by the CA and is "usually" signed, but doesn't tell how the makes its way to my browser.
http://en.wikipedia.org/wiki/Certificate_revocation_list#Publishing_Revocation_Lists [wikipedia.org]
A CRL is generated and published periodically, often at a defined interval. A CRL can also be published immediately after a certificate has been revoked. The CRL is always issued by the CA which issues the corresponding certificates. All CRLs have a lifetime during which they are valid; this timeframe is often 24 hours or less. During a CRL's validity period, it may be consulted by a PKI-enabled application to verify a certificate prior to use.
To prevent spoofing or denial-of-service attacks, CRLs usually carry a digital signature associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed, which can usually be found in a public directory.
The certificates for which a CRL should be maintained are often X.509/public key certificates, as this format is commonly used by PKI schemes.
I don't trust CAs (Score:2)
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.
Re: (Score:2)
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
Self Signed Certificates (Score:2)
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.
Re: (Score:2)
If you want to fix the problem, start lower in the OSI layer. HTTP has never been designed as a secure protocol, and HTTPS is a crutch rather than a solution.
Re: (Score:2)
I disagree. A self-signed cert can only assure you no one is able to eavesdrop, not that you're talking to the right server. However, self-signed certs should be treated like any plain old HTTP connection, since they're more secure than those, even though browsers make them feel less secure than those.
Re: (Score:2)
Trust me, I had this discussion here often enough with the same faulty points are being regurgitated over and over.
http://it.slashdot.org/comments.pl?sid=1690388&cid=32611676 [slashdot.org]
http://it.slashdot.org/comments.pl?sid=2417038&cid=37328184 [slashdot.org]
http://it.slashdot.org/comments.pl?sid=2382470&cid=37111036 [slashdot.org]
http://it.slashdot.org/comments.pl?sid=2053436&cid=35611648 [slashdot.org]
http://tech.slashdot.org/comments.pl?sid=2419404&cid=37345104 [slashdot.org]
http://tech.slashdot.org/comments.pl?sid=2403804&cid=37250882 [slashdot.org]
http://tech.sla [slashdot.org]
We gotta stop outsourcing trust (Score:1)
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
Re: (Score:1)
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.
This is why I love IT (Score:2)
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.
Bah CA's (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
I think people have missed the alternative to CAs. (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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