Slashdot Mirror
Hackers May Have Nabbed Over 200 SSL Certificates
CWmike writes "Hackers may have obtained more than 200 digital certificates from a Dutch company after breaking into its network, including ones for Mozilla, Yahoo and the Tor project — a considerably higher number than DigiNotar has acknowledged earlier this week when it said 'several dozen' certificates had been acquired by attackers. Among the certificates acquired by the attackers in a mid-July hack of DigiNotar, Van de Looy's source said, were ones valid for mozilla.com, yahoo.com and torproject.org, a system that lets people connect to the Web anonymously. Mozilla confirmed that a certificate for its add-on site had been obtained by the DigiNotar attackers. 'DigiNotar informed us that they issued fraudulent certs for addons.mozilla.org in July, and revoked them within a few days of issue,' Johnathan Nightingale, director of Firefox development, said Wednesday. Looy's number is similar to the tally of certificates that Google has blacklisted in Chrome."
All of the news about the SSL security flaws are starting to get boring. We had a related scandal just yesterday. The problem with SSL (or TLS, actually) is that it uses X.509 with all of its problems, like the mixed scope of certification authorities. It's like using global variables in your program - it is never a good idea. I can only agree with Bruce Schneier, Dan Kaminsky and virtually all of the competent security experts that we have to completely abandon the inherently flawed security model of X.509 certificates and finally fully embrace the DNSSEC as specified by the IETF. It is both stupid and irresponsible to have a trust system used to verify domain names in 2011 that is completely DNS-agnostic - and in fact designed in the 1980s when people were still manually sending the etc/hosts files around! There could be a lot of better solutions than the good old X.509 but in reality the only reasonable direction that we can choose today is to use the Domain Name System Security Extensions. Use 8.8.8.8 and 8.8.4.4 exclusively as your recursive resolvers. Configure your servers and clients. Define and use the RRSIG, DNSKEY, DS, NSEC, NSEC3 and NSEC3PARAM records in all of your zones. Use and verify them on every resolution. Educate people to do the same. This problem will not solve itself. We have to start acting.
Karma: Positive (probably because of superiour intellect)
So, I still say that if trust is lost once, nothing that Diginotard touches can ever be trusted.
There's nothing wrong with public key cryptography. The issue is with the way it's handled, specifically the CAs.
The stories and info posted here are artistic works of fiction and falsehood.
Only fools would take it as fact.
CAs are done, stick a fork in 'em. Just generate your own certs. A CA cert only increases your chance of getting MITM'ed (since you don't have sole control over distribution), and without a big store of certs in one place, they'll be harder to steal.
Fuck CAs, install Convergence / Perspectives, call it a day.
"When information is power, privacy is freedom" - Jah-Wren Ryel
...wouldn't the certs be useless without the associated private keys?
Seriously, I wonder what percentage of software actually checks the CRL's. It's extra steps that are annoying to code and I bet a lot of programmers just skipped it.
So even though these certs have or will be revoked that doesn't mean you're safe. If the programmer(s) of the software you're using were lazy and didn't code the extra steps to get the CRL's (or maybe the CRL itself is inaccessible for some reason) then you're screwed.
This is one of those things that programmers would have never considered until it actually became a real issue.
How long until we collectively admit that centralized SSL certs are actually causing more problems than they solve?
The SSH model works great: connect to a site once; verify the fingerprint once if you consider a MITM to be a reasonable concern; cache the key and know that forever after you're connecting to the same site as you did the first time. That narrows the attack vector to active MITM attacks where Mallory can intercept your first connection (if they want to actually get your data) and every connection thereafter (if they don't want to be noticed). It makes widespread surveillance impossible (they'd be noticed) and targeted attacks very unlikely to succeed.
You can even add a CA to that model: have the first-time dialog be "[ nobody | ] certifies that is . Does that sound OK to you? (looks good) (hell no)". In other words, just make self-signed certs less scary, and CA-signed certs more scary... Which would accurately reflect the actual level of security you're getting: both are probably OK, and one is a little more certified but certainly not golden. Only pop up the BIG SCARY WARNING when the cert changes, even if it's signed by the CA.
Clearly there is something wrong with public key cryptography, otherwise we wouldn't need the band-aid "solutions" that CAs and the chain of trust concept are.
Let's say you were hoping to insinuate yourself unnoticed into traffic destined for a particular site - for the sake of argument, let's use the Tor project. What would be the best way to do this without someone suspecting you had a specific target in mind? Stealing a couple hundred certs all at once, only one of which is related to your project, comes immediately to mind.
It's not like similar approaches haven't been taken before, even in the non-digital world. I seem to recall that was one explanation John Muhammad gave for the DC Sniper attacks - he really wanted to kill his ex-wife, and hoped killing a bunch of other people would keep suspicion from him.
#DeleteChrome
Chain of events as follows:
1) Fraudulent issue of certificate
2) Revocation of certificate
3) Clients find out...how?
As an example, I downloaded the cert Google offered up on encrypted.google.com. It had no OCSP specified, but it did have a CRL specified. Now, is Firefox checking the CRL embedded in the cert or not? I think it is, but the only way to confirm would be to actually try to hit a site with a revoked cert. FF by default is configured to only use OCSP if the cert has the information embedded in it, which this Google cert didn't. Which doesn't give me the warm fuzzy about other certs, either. I checked a few others. The Verisign sites, including RapidSSL, have an OCSP URI embedded. So that's better.
My point is that the whole revocation business remains slipshod and saying that you 'revoked' the certificate doesn't mean a hell of a lot in reality.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
Why are you resorting to name calling? Why resort to ad hominem if you're correct? Oh, that's right, you aren't. You're absolutely wrong, and the GP is the one who is correct. Nice try, though.
I'm sorry that your religion revolving around CAs and PKI has been shattered, but there's no need for you to take that out on other people. The fear and uncertainty you feel at the moment will pass, but only when you admit how wrong you are.
If you keep a spare house key on your front porch in a metal box marked spare house key you'll be robbed sooner or later. This is not a flaw of the lock and key security.
The public key system is working fine. What is not working so well is the trust model. The current system is fatally flawed in that security depends on none of the many many CAs failing. It doesn't matter if you choose a high quality CA to sign a cert for your site, your users can still be fooled by a backwater CA you've never heard of before and wouldn't trust to guard a dime.
It's true that in DNSSEC, it is potentially a huge logistical nightmare if a party entitled to 'bless' public keys as yours is persistently compromised (basically, an unprecedented display of ongoing incompetence to always be open to hijack).
However, on the flip side, the relatively long lifetime of certificates incurs the nastiness of CRLs and some amount of faith that CRLs make it to the right place at the right time. If a DNSSEC authority is compromised and fixes it in an hour, all signs of the compromise evaporate in less than a day. If a CA is compromised, you could potentially have years of potential threats if a hapless client doesn't get a CRL update. That's the biggest problem with x509 at internet scale, long term risk to existing credentials because of the relatively outdated goal of avoiding frequent communication with an authority.
XML is like violence. If it doesn't solve the problem, use more.
I ignore those warning boxes anyway.
Realize that the "area their organization controls" can be vastly increased, like China Telecom showed. http://bgpmon.net/blog/?p=282
That's not several dozen, that's a few gross.
http://lair.fifthhorseman.net/~dkg/tls-centralization/
Laws are like sausages. It's better not to see them being made. - Otto von Bismarck
Can't see anyone having posted this, but Mozilla have instructions on how to remove DigiNotar as a trusted CA in your Firefox. I'm sure other browsers have similar processes.
I also note they've just released a new Firefox (and Thunderbird) version that has removed the CA entirely - good response:
Because the extent of the mis-issuance is not clear, we are releasing new versions of Firefox for desktop (3.6.21, 6.0.1, 7, 8, and 9) and mobile (6.0.1, 7, 8, and 9), Thunderbird (3.1.13, and 6.0.1) and SeaMonkey (2.3.2) shortly that will revoke trust in the DigiNotar root and protect users from this attack. We encourage all users to keep their software up-to-date by regularly applying security updates. Users can also manually disable the DigiNotar root through the Firefox preferences.
Let the next time someone in that company try to "google" something be a very unpleasant experience.
Google death sentence.
With HTTPS, the people you trust are the few hundreds of CAs your browser is configured to trust. It's way too many, and your vulnerability with them is a logical OR -- any CA fails and you are vulnerable. It's a fucked up system. However, at least you can remove DigiNotar from your browser's trusted list.
With DNSSEC, you trust the root. They are your "trust anchor". And you get no choice about it.
Each system is fucked up.
This relates to the concept of "trust agility" that Marlinspike discussed. He wrote it up in a blog entry. I highly recommend reading it and understanding it. You can get to the blog by the first link in this Slashdot article a couple weeks ago.
over 200 can be expressed as a multiple of 12! In fact, more than 200 can potentially be 17 dozens!
SSL And The Future Of Authenticity, Moxie Marlinspike:
Worse, far from providing increased trust agility, DNSSEC-based systems actually provide reduced trust agility. As unrealistic as it might be, I or a browser vendor do at least have the option of removing VeriSign from the trusted CA database, even if it would break authenticity with some large percentage of sites. With DNSSEC, there is no action that I or a browser vendor could take which would change the fact that VeriSign controls the .com TLD.
If we sign up to trust these people, we're expecting them to willfully behave forever, without any incentives at all to keep them from misbehaving. The closer you look at this process, the more reminiscent it becomes. Sites create certificates, those certificates are signed by some marginal third party, and then clients have to accept those signatures without ever having the option to choose or revise who we trust. Sound familiar?
The browser CA model is screwed up. DNSSEC is screwed up. What's the answer?
I think Marlinspike was smart to start with defining the problem. And now, with Convergence, he's also trying to address it. Check it out. (And check out Perspectives. Perspectives is the project he based Convergence on.)
"He's resorting to name calling, which means he's wrong" is itself an ad hominem.
Public key crypto is not the same thing as the current browser HTTPS CA trust model. Make the distinction and you'll be better able to understand him.
Blaming hackers, foreign governments and "them" after security compromised? Absolute garbage, then to follow up on their malfeasance they did not disclose the full extent of the breach.This plays like a broken record, no penalties and no responsibility.
A provider of physical security ( locksmith or alarm technician ) are bonded against screwups, why can't cert vendors do the same?
Seriously. A state has shown itself to intentionally and willfully hack, and yet they are allowed to stay connected? Why haven't they been cut off?
http://www.mozilla.org/en-US/firefox/6.0.1/releasenotes/
Expand "what's new" to see the change.
Update immediately if this is worrysome to you.
These certs were revoked yesterday in an out-of-band patch.
Yeah, and why not hunt down the people who run the company and execute them? /sarc
Send their ashes into the sun, burn down their house, and remove their names from all public record and make it illegal to ever speak of them again?
Screw that, i moved to Convergence.
Artix
Your Linux, your init.
The problem here is that any CA that is in my list of root certificates is able to create a valid certificate for say www.google. com, and that some CA can be tricked into giving someone other than Google such a certificate. That is not enough, the attacker also has to redirect traffic that should go to www.google. com to their own server. The whole thing is mostly dangerous because _many_ people go to www.google. com in the first place; the same attack against say my homepage would have very little potential to cause damage.
Here is what browsers could do: Every time you visit a website and get back a certificate, record which CA issued the certificate. Then if www.google. com suddenly returns a certificate from a different CA, the browser can give you a warning. Now if I use Google to look up information about platypuses in Australia, I might not care. If I use it to find information that I know my government wouldn't want me to look at, I would be careful. If I give my credit card to Amazon and the CA has changed, I would be careful.
The attack would therefore be greatly reduced to users who just have a brand new computer with no browsing information yet.
Not like it matters.. see Moxie's talk on SSL.
Why settle with just revoking the certificates? I may be wrong with this, but if the certificates are stolen and revoked, people shouldn't bump into them any longer unless they are used by the criminals. Instead of just saying "Hey, this cert isn't valid" why not put out a big warning that someone is doing nasty things on your connection right now.
Only dumb birds land downwind.
You are a moron if you think this is a cryptography problem. The cryptography works fine. The chain of trust is the problem. If you were to drive over to google with a thumb drive, get their certificate, install it and use just that for your encrypted connection to google.com you are fine. The problem is you are trusting some unknown third party for google's keys. If you think that is a good plan for security I have a plankpad errrr..... ipad I can sell you tonight in a parking lot.
Get a web developer
Well, that sounds like it might be a little excessive.
No, it is a flaw of lock and key security because the human who operates the system is as much a part of it as the lock and the key. Though you might not blame the lock or key for that specific incident it is still a problem.
This is not to say that it is convenient or even possible to design a flawless security system, only that there is progress to be made in keeping one's eyes open as to the ways they can go wrong.
"Sacrifice for the good of The State" - The State
Yeah, and why not hunt down the people who run the company and execute them? /sarc
Send their ashes into the sun, burn down their house, and remove their names from all public record and make it illegal to ever speak of them again?
My general desire for Freedom of Speech requires me to object to that last part of the proposed punishment. After all, it'd be useful to be able to mention them when using them as an example of what not to do.
The rest sounds reasonable.
"Little does he know, but there is no 'I' in 'Idiot'!"
With the nightly FF and Chrome updates... and god only knows about IE8/IE9, the consumer environment seems to be covered, but what about the enterprise? Seems like the argument for moving away from central CA's is making more sense.
Currently deleting CA certificates on OS X will still render sites secure in Safari and Chrome, changing their status to "Do Not Trust" works but alas. iOS devices have a similair problem, there is no interface to revoke certificates. Until this is fixed, SSL security on these systems is a joke.
That's a splitting of hairs that's worse than useless. We might as well cease looking for fault and just declare it all human error. Since we can't rid ourselves of that, we can then stop trying.
Or, we could actually try to make useful distinctions.
I get the impression that how we choose is going to be one of the primary issues going forward.
Currently, Perspectives allows you to specify which notary servers you'd like to use (and what percentage of them must agree (and for how long)).
But how convenient is that? I imagine people might choose notary configurations much like how they subscribe to DNSBLs or choose Ad Block filter subscriptions.
No it isn't, that is how we got locksets that stay locked, ones that relock on a timer, ones that can remind you if you've left them unlocked. It is why my vehicle dings at me if I leave the keys in the ignition (or the lights on). If I forget to lock my office door and someone steals my stapler, no big deal really. If I forget to lock the front door of the nursery and someone steals all the babies, big deal. So we consider the human element in designing the locks for those two places, despite the fact that any reasonably decent lock and key set would 'secure' them equally.
"Sacrifice for the good of The State" - The State
Not really no. We didn't get a single one of those things by blaming the lock and key system for human errors. We got them by recognizing that the lock and key work fine but the human needs a reminder or 3.
Had we instead blamed the lock and key, we'd have some other security system or (by now) we'd have just given up.