Slashdot Mirror
Diginotar Responds To Rogue Certificate Problem
An anonymous reader writes "Vasco, the owner of the DigiNotar CA implicated in the MITM attacks on Iranian Google users has responded to their fraudulently issued certificate problems. The press release reads: 'On July 19th 2011, DigiNotar detected an intrusion into its Certificate Authority (CA) infrastructure, which resulted in the fraudulent issuance of public key certificate requests for a number of domains, including Google.com. Once it detected the intrusion, DigiNotar has acted in accordance with all relevant rules and procedures. At that time, an external security audit concluded that all fraudulently issued certificates were revoked. Recently, it was discovered that at least one fraudulent certificate had not been revoked at the time. After being notified by Dutch government organization Govcert, DigiNotar took immediate action and revoked the fraudulent certificate'. It is not clear whether the latter certificate is the one used in Iran, or whether other certificates remain at large. I guess removing the root certificate from browsers is the correct response."
Looks like the Iranians learned a neat trick from that attack.
SJW: Someone who has run out of real oppression, and has to fake it.
... how many forged certs are now in the wild? Nuke the CA, they are incompetent.
1) Options -> Advanced -> Encryption -> View Certificates
2) In the Certificate Manager window, click the Authorities tab.
3) Scroll down to DigiNotar.
4) Delete or Distrust the "DigiNotar Root CA" certificate.
or you can be sure that iranian authorities don't interfere.
were all victims from iran?
world was created 5 seconds before this post as it is.
I just removed the trust setting from this CA in my browser. So can anyone else. Anyone know a site for which they've issued a cert to test and see if this actually makes any difference?
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
So not only did they hide a break-in from the internet at large, including companies (e.g. Google) which were by extension the target, but they also aren't able to tell how many or what kinds of fake certificates got generated by the break-in? If you ask me their entire CA needs to be revoked, and a new one started. They can then re-issue all legitimate certificates under the new CA. That is the only safe way to do it.
Cost, I presume. With an air gap someone has to physically take a USB key to the other machine to get the key signed, and that adds cost and people want to buy certs cheap.
Of course the end user who's relying on those certs has no way of ensuring that they weren't generated by a cheap CA which doesn't take serious precautions to prevent this kind of thing.
Ultimately the whole CA system is broken because any company can issue any key for any site, so we're all reliant on the least secure CA that the browser trusts. Worse than that, the browser doesn't even tell you that they key has changed unexpectedly (e.g. without the old key expiring), which would go a long way toward eliminating these kind of attacks.
Can someone explain why a .nl organization has the power to produce .com certs? I mean, isn't this an obvious flaw in the domain/ssl/registrar/CA/whatever hodgepodge we take for granted everyday? Is it even possible to limit these guys or is it "Hi, you're a CA now, you can do anything!"
I remember the same thing happening with a different foreign CA not too long ago and a lot of hand wringing over state owned telecoms in China/Iran/Syria and other autocratic nations. The domain name system works like this. China can make all the .ch domains it wants, but a Chinese CA can make all the .com SSL certs it wants? That's fucked up.
We REALLY need a better way to handle root CAs.
First, there should be one list of CAs for the system - not one for every application on the system. Why should Firefox, Thunderbird, Chrome, IE, and who knows what else all have an embedded list?
Second, that list should be easy to update without having to download new copies of all your software.
Ideally, that list should have its own CRL of sorts - so that automated revokes of root CA certificates can be done with a simple process. That should be a fail-safe mechanism - if the CRL can't be authenticated in some period of time, then a warning is displayed or all certificates relying on that CRL become invalid.
problem faced by governments. namely, how do we spy on the public without their knowledge to ensure they remain compliant to the states will?
in iran the middleman is obtained nefariously as third and second world nations are excluded from participation in general surveillance as a matter of ideological
principal on the part of wealthier and larger nations. in a sense this is to ensure that "our spying" is ideologically valid and just in the public eye, while
"their spying" is only for evil purposes and not to enforce a relatively tolerated theocratic government. american authority figures however simply access the service providers directly. Frameworks are even provided
at the request of the government to facilitate warrantless surveillance of the populous, for any reason, through various internet services.
this abuse of CA by iran is problematic not because theatens the security model, but because it undermines the infrastructure by which america and other wealthy nations ensure the sanctity of their firstworld economic transactions; the lifeblood by which they operate.
Good people go to bed earlier.
DigiNotar CA is now removed from my list of trusted root CA:s.
I propose that all web browsers and other application should do the same since it's not certain how many compromised ones there are out there.
Or that the private key for the root CA was kept safe.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
We at Vasco love the passive voice more than our own mothers. Also, all appearances to the contrary, we aren't colossal fuckups because, when we colossally fucked up, we "acted in accordance with all relevant rules and procedures"(this apparently didn't include mentioning that there had been an issue). Thankfully, we hire external auditors who operate well on our level of understanding, so they didn't reveal the embarrassing scope of our failure. After somebody else entirely did our job for us, we finally got around to cleaning up what of our mess was still within the realm of fixable(sorry, Iranian Gmail users, hope you weren't doing anything seditious..)
So, is there any reason that this company shouldn't just be sold for scrap now? Their security clearly isn't good enough, their secretive attitude isn't exactly in line with being a 'trusted' certificate authority, and they can't even hire the right outside assistance to help them clean up their own messes. Hell, at this point, my very own FuzzyFuzzyFungus' SporeCert(tm) trust solutions would appear to be a better bet...
The sucky part of that is that's who I get my email pgp keys from. But really there needs to be a tiered CA system, where a CA is providing certs to anyone that asks, to people that have to prove themselves, and to government and other trusted sources. The way things are now, pulling the plug on an entire CA is the nuclear option.
I work for the Department of Redundancy Department.
Currently, root certificates are wildcards, usable for any TLD. They need to be restricted to a single TLD, or a short list.
Single-nation CAs and government-operated CAs should be restricted to their TLD. For the generic TLDs, ("com", ".net", etc,) the CA/Browser Forum should require the CAs to post a large bond, from which a penalty is forfeited if any improperly issued cert is found. That should get the problem under control.
Could one not send CSRs to more than one CA and the browser indicates how many CAs responded ok?
F-secure claims Diginotar was repeatly hacked since May 2009; it shouldn't be trusted at all:
http://www.f-secure.com/weblog/archives/00002228.html
Too little, too late. I already removed DigiNotar from my trusted CA list. You should too. In Firefox: Options > Advanced > Encryption > View Certificates > Authorities tab > Find DigiNotar > Edit Trust.
that's unnecessary. Build a machine with OpenBSD on it, put a write only disk into it for sharing, 2 separate network cards and then create an account for using scp between the machine and network 1 and machine and network 2. Have network 2 generate the certificates and be off the Internet, but have network 1 be on the Internet. Poll the files from the machine every once in a while.
You can't handle the truth.
Confirm that it is in fact removed. The last time I tried that (IE 6?), it reappeared the next time I started the program.
If I used a sig over again, would anyone notice?
this is a good day for liberties, because this kind of sh...stuff exposes any type of 'authority' for what they really are, be it a gov't or any other so called authority (especially the kind that people just trust without questioning).
Since when are people just blindly trusting one another? Government like structures? Isn't this a sure way to get completely screwed by whoever you are trusting?
The entire model is wrong, of-course. There is a need for a bunch of competing systems, open, distributed, easy to verify lists, that can be compared one to another, with time stamps, with hash keys, it needs to be thought through, but there is a need. It has to be distributed so that there is no one central authority. I want to be able to check the fingerprint of a certificate against multiple competing distributed signed lists and as an admin of a system I want to be able to check what those lists maintain as fingerprint for my sites as well and quickly fix any problems if they happen. This is complicated but it will have to happen.
You can't handle the truth.
http://www.f-secure.com/weblog/archives/00002228.html
But still in further statements they continue to claim that the trust in other certificates managed by the same company (under a different root) is not affected by all this.
First, that indicates that they have no clue what trust means, but also it is not at all unlikely that they have to announce next week that a fraudulent certificate was still issued, only their broken auditing system had not been able to trace it.
How does that help? If the key-signing computer just signs any keys submitted to the intermediate system then anyone who hacks into the network can send keys to the intermediate system and wait for the signed certificate to appear there.
I am only talking about having the certificate issuing computer on a network, loosely connected to the network that is connected to the Internet, only talking about not needing a 'USB data transfer' approach. So this would prevent the certificate issuing system from being compromised and that is important, since CA's private keys are there (and the signing code is there).
As to the other question of how should anybody be prevented from submitting requests to have certificates generated for domains that do not belong to that requester - I am actually quite against CAs in the first place and that's part of the reason - I don't know who submitted the request and who the hell is signing it.
You can't handle the truth.
Should also check the bank accounts of DigiNotar employees to see if any got an unexplained bonus.
So this would prevent the certificate issuing system from being compromised and that is important, since CA's private keys are there (and the signing code is there).
But... they... don't... need... those... keys.
Their goal is to get fake keys signed. If they can break into your network and submit their fake keys to the signing system and get signed certificates back, then they have succeeded. Obviously stealing the signing keys would be better, but so long as they can get the fake certificates they want, then they don't much care.
All you've done is converted an attack on the signing computer into an attack on the intermediate computer. That's a difference that makes very little difference.
open /Applications/Utilities/Keychain Access.app
Click on System Roots
Scroll down to DigiNotar Root CA
Click the "i" icon, or select "Get Info CMD-I"
Expand the "Trust" node
For the "When using this certificate"
Select the "Never Trust" option
If successful, the info window will now say "This certificate is marked as not trusted for all users"--- and you can browse this site to ensure that the trust is broken.
An air gap won't help. This was almost certainly an inside job with the intrusion blah-blah as a cover story. Somebody was paid.
Yes. But we are in a thread that discusses an "air gap" that's all. You are not in a thread that discusses how to prevent false requests from being processed. The air gap wouldn't have prevented that either and this is not what we are talking about in this specific thread.
To fix the problem that you are talking about - the false requests planted by whoever SUPPOSEDLY (and I don't believe that it is what happened there) broke into the system you need to have something else altogether. There has to be a way to verify that the request itself is legitimate. I in fact had to deal with this, I actually got a CA to generate a certificate for a company and send it to me, they didn't really know who they were talking to. This happened maybe 5 years ago and I am not going to get into specifics of what CA and what company that was.
You can't handle the truth.
If you are still using IE6 you have bigger problems than diginotar...
How does one remove that particular CA from one's CA bundle?
How does one remove that particular CA from one's CA bundle?
It depends on the browser. For Firefox you open the options, select "Advanced", click on the "Encryption" tag, and press the "View Certificates". Select "DigiNotar root CA" from the list (just start typing the name and the cursor should jump to it) and press "Delete or Distrust". Lots of steps, but all-in-all quite a simple process.
I haven't refreshed this page yet so I don't know if someone has already mentioned this, but it might be a better idea to click on "Edit Trust" instead of "Delete or Distrust" so that you can more-easily alter your policy for that CA later if you change your mind.
Already done. https://www.ironkey.com/trusted-access
Apparently even protects against man-in-the-middle attacks and keyloggers.
Thanks! I just deleted it. One can always add exceptions for specific sites if I need to. Personally, I think they should be removed entirely from the CA bundle. Trusted CAs need to be held to a very high standard IMHO.
Why do we have these CAs around? A completely decentralized system that has no system of control whatsoever. All you need is for some company to manage to somehow convince some browser venders that they have good security policies. And with that, everybody around the world is basically forced to follow in that "trust". How fucked up is that anyway.
At the same time, the whole thing is so tightly coupled with DNS already. The common name has to be the domain name. So why the heck are these CAs separate from that? At least DNS has a control body. CAs have nobody but the browser vendors; and they don't report to them.
I say dump the current CA trust model. Make all DNS root servers a CA, let them issue CA certificates to their registrars, and let the registrars issue certificates to their customers, and only for those domains that their customers have registered under them. Publish the certificates in the domain's DNS records. Make ICANN compose strict rules that all registrars must obey, just like they already do before they allow registrars to service TLDs. And punish violations by revoking the registrar's certificate. Install all DNS root certificates in all OSes, and force those OSes to keep a local OCSP cache that is no older than a few minutes at any given time.
What are we doing fucking around with trusting arbitrary companies that survive on charging exuberant amounts of money to do openssl commands, and have no form of oversight whatsoever?
``OK, so ten out of ten for style, but minus several million for good thinking, yeah?''
Correct me if I'm wrong, but assuming we can achieve secure DNS, it becomes much more simple to associate a site's certificate with only the associated domain registrar, instead of the HTTPS equivalent of allowing any registrar to vouch for a certificate.
As other posts have noted, part of the problem is that ANY of the certificate authorities can vouch for a certificate. By keeping the trust path narrow (root->singular registrar->domain) instead of wide (root->all registrars->domain), breaches in trust will have less of an effect.
Of course some jobs are best left to governments. This just isn't one of them.
Governments are in the business of spying on people. Sometimes legitimately, sometimes not, but regardless it's not in the interest of the person being spied upon for it to happen, and so governments have no business in the chain of trust. They're near the top of the list of actors we specifically don't trust.
With every domain name you own you should be able to get an SSL cert with your registration/renewal. I want to register this domain and here is my CSR as part of the registration process.
CAs were supposed to verify you independantly of domain ownership so that identity problems such as bad actors getting certs for gooogle.com..could not occur.
Today the process has been soo watered down humans are too many cases not even in the loop. All distinction between identity and domains for all practical purposes does not exist.
Give everyone with a domain name their own SSL certs and stop throwing money at CAs. The network will be marginally safer for it.
I hope this incident leads browser makers to adopt more realistic certificate husbandry mechanisms, such as alerting me when my bank's cert changes.
Those should not be permitted to run CAs.
Canada is a wonderful country, but even it has it's flaws. Why give it the temptation of running a CA when there's no need for it to do so? Further, imagine how much damage a rogue nation like Iran, North Korea or the United States could do with one.