Diginotar Responds To Rogue Certificate Problem 177
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."
Wasn't a forged certificate a big part of Stuxnet? (Score:2)
Looks like the Iranians learned a neat trick from that attack.
or you can be sure that iranian authorities don't (Score:2)
or you can be sure that iranian authorities don't interfere.
were all victims from iran?
Re: (Score:3)
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.
Re: (Score:2)
Should also check the bank accounts of DigiNotar employees to see if any got an unexplained bonus.
Re: (Score:2)
How does one remove that particular CA from one's CA bundle?
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
If you are still using IE6 you have bigger problems than diginotar...
So they don't know... (Score:4, Insightful)
... how many forged certs are now in the wild? Nuke the CA, they are incompetent.
Already done (Score:2)
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?
Re: (Score:2, Informative)
check their site, they sign their own certificate ::
https://www.diginotar.com/Products/ExtendedValidationSSL/tabid/622/Default.aspx
Re: (Score:2)
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?
Their own [diginotar.nl] (it just redirects to the non-SSL site, but that should be sufficient for you).
Re: (Score:3)
A lot of (most?) dutch intra-government traffic uses their certificates.
See https://loket.amsterdam.nl/ [amsterdam.nl] for instance
Re: (Score:2)
Um, no. Google's true CA is not DigiNotar, but Equifax, according to the cert from encrypted.google.com [google.com]. The rogue MITM cert for *.google.com was issued by DigiNotar, but there's not really a way to test this without altering DNS to point to the rogue site. Also, that cert was already revoked ("were you not paying attention?"), and I want to test revoked trust for all DigiNotar.
This should be obvious.
Re: (Score:2)
Um, no. Google's true CA is not DigiNotar, but Equifax,
Whoosh
Re: (Score:2)
Why bother? Microsoft, Mozilla, and Google have all already removed the trust on that CA Root certificate (Apple is notably absent). Your next desktop update should nuke it for you.
Re: (Score:2)
True enough....
But the whole framework behind certificates and CA's is the problem. This is just a symptom of the problem.
Moxiespike: "Who are you going to trust, and for how long?"
If the answer to how-long, is forever - then you probably have a problem.
The problem is there's no real way to handle problem CA's - and you don't get much choice, and the system is too moribund and static to respond to problems like this.
So, yes we can fix this *specific* problem by getting every browser to re-work the trusted C
Re: (Score:2)
Of course, Convergence relies on the user having any clue whatsoever of whether (s)he should trust a particular Notary or not.
We're talking about users who use the same password repeatedly, who use mostly 6 and 7 char passwords, who use 'password' and '123456', etc.
Re: (Score:2)
But it doesn't have to stay that way.
A vendor could easily offer a service to customers that would be the expert in choosing the notary's who are trustworthy, perhaps offering their own notary service as well. Now the vendor selling this service has an incentive to actually protect the user - since if they don't, they lose trust and then lose the customer and their dollars.
And given a little time I'd guess there would be several stable notaries out there and would be well trusted.
There would be services tha
Re: (Score:2)
The web has a problem. How do we tell if a URL is trustworthy?
I know, lets create certificates backed by certificate authorities!
Now the web has two problems.
Re: (Score:2)
Especially since even if you revoke a certificate it still requires that someone checks the revocation list - and if you are behind a wall or suffer from a man in the middle, can you be sure that the revocation list is the correct one?
Once a CA is failed - it's completely and utterly failed as a trusted entity. And if someone got hold of the private CA key - then it's a clusterfsck.
Re: (Score:2)
Any competent CA uses an HSM. I can even imagine using an HSM is a requirement for inclusion into the default CA bundle in webbrowsers.
An HSM is a Hardware Signing Module. It's a piece of hardware (supported by OpenSSL, by the way) which holds the secret keys. Secret keys cannot possibly be copied out of the HSM, except for backup purposes. But the backups are encrypted within the HSM itself, so the backed up keys can't be used for signing.
Diginotar, as most CA's I know of, uses multiple secret keys. One ke
Re: (Score:2)
But it still doesn't resolve the fact that the revocation has to be propagated, and it's not often working well with certificate revocation lists - often due to user error and trouble setting up the CRL handling in the web browser or other application.
Re: (Score:2)
Re: (Score:2)
OK whether they are incompetent or not is another matter, some questions arose from this whole issue.
From other comments it seems there is no system in place to automatically revoke certificates. I really don't understand this, such an oversight. Breaches can not be prevented, no matter how hard you try (and of course the CAs should do their utmost best), so there is a need for revoking any certificates automatically and instantly. For example by having the browsers check a CA with the issuer or at DNS lev
Re: (Score:2)
I know they are incompetent of fraudulent enough to issue a certificate for *.google.com. What more do you need to know?
In Firefox 6 (Score:5, Informative)
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.
Re: (Score:3)
And do the same for Comodo while you're at it.
Re: (Score:2)
And do the same for Comodo while you're at it.
Care to explain why?
Re: (Score:2)
http://www.f-secure.com/weblog/archives/00002128.html [f-secure.com]
Re:In Firefox 6 (Score:4, Informative)
In short, Comodo has issued fraudulant certificates for Google Mail, Yahoo, and a couple other high traffic sites. Gameboy is correct - nuke both of these CAs immediately.
Re comodo (Score:2)
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.
Re: (Score:2)
I agree that government would be a logical choice to provide this service. It would be sensible to build a geographic web of trust, where citizens authenticate themselves with the municipality, the municipalities trust the governors, and the governors trust one another.
I would also enjoy the conspiracies that this model would create.
Re: (Score:2)
Re: (Score:3, Insightful)
That's because you're a paranoid wingnut. Believe it or not there are some jobs best left to the government. If you genuinely feel that way, Somalia is =========> that away.
Re: (Score:2, Troll)
there is no longer a single job that I can point at and say: gov't can do this or should do this or must do this. Anything I look at and I see gov't in there, I know it's all completely screwed up.
BTW., that's why people came to USA - for less gov't. Now they have to go to Somalia all of a sudden? I believe attempting to fix what is found locally is the first thing to do.
Re: (Score:2)
Most don't want to "fix" the US the way you do.
Re: (Score:2)
They do have a choice, whether it's the right choice is irrelevant, the vast majority will not vote the way you do so your "fix" is quite impossible to pull off in the US.
Re: (Score:2)
We're not bankrupt, we're just spending more than we're taking it. We definitely can balance the budget, it's just that the partisans on the right don't want to do the cutting of military expenses or raise taxes on the wealthy that would be required to make it happen. The spending on unemployment and social programs is really what we need to do to pul ourselves out of this current economic malaise. Corporations aren't going to create jobs if there isn't demand for their products and services.
But, we've stil
Re: (Score:2)
Good, the last thing we need is more incompetent business people in the US. In fact you've just convinced me that I need to do whatever I need to do to ensure that Ron Paul loses. Perhaps all those business people that ran their businesses into the ground will leave for some other nation.
Re: (Score:2)
Re: (Score:2)
Real choices? Bull-fucking-shit. All it does it create private monopolies - even worse than government monopolies in that you don't elect the people in charge of those, and their goal isn't to have power it's to extract money. Every country that's ever privatised its water has suffered a minimum of ten-fold increase in charges, and it's the poor that suffer. But hey, you're not poor so why do you give a shit about those scum right? Screw the poor. Power to the rich people!
Re: (Score:2)
That's flat-out bullshit - citation please.
Re: (Score:3)
Somalia has no functioning government, and therefore does not protect the LIBERTIES of the individual, which is the purpose of government.
Re: (Score:2)
Which is a large part of why I still reside in the US. As bad as things have been in some areas, it still beats the hell out of much of the world. Personally, I think we're doing enough right that we're better off fixing the things that aren't working than junking the entire system.
That's not to say that the President hasn't been a major let down with regards to progress on GITMO and fixing the tax problem.
Don't be silly (Score:3)
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.
Re: (Score:2)
Governments are in the business of spying on people.
Goodness! Are they really? It's a good thing that private corporations aren't in the business of harvesting and selling personal data to the highest bidders, then. Let me create a Facebook profile right away!
Re: (Score:2)
... sayeth somebody who lives under the umbrella of one of the most successful, free-society-fostering governments on Earth.
Yes, our government has its share of flaws, and we should work to correct them. But it's idiocy to claim that one of the most successful systems ever devised should be unilaterally dismissed.
Re: (Score:2)
Absolute power corrupts absolutely, in other words. The best way to not tempt the govt. is to never given them the power to start with.
Re: (Score:2)
And yet you're posting on a network funded by US government dollars, using a protocol devised using money from multiple international governments.
Of course, you being a completely-round-the-bend loony, you're going to fabricate reasons why this is not blatant hypocrisy.
Mart
Re: (Score:2)
The entire point of SSL is that you don't trust the network.
Re: (Score:2)
Yep. Completely round the bend. Absolutely bonkers.
And like I predicted, spinning like top. You said you wouldn't trust anything built by a government. You weren't arguing that there might have been a private alternative, so now you're just shifting the goalposts. Again: I would never in my entire life trust a gov't of any kind to do [any work].
Your words. So what are you still doing here?
Re: (Score:2)
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.
Why do you need to get your email pgp keys from *anybody* except yourself? There are very few transactions where someone needs to know your actual identity. Most of the time, they need to know that you are the same person they talked to last time. Meet someone online (or even IRL) and exchange keys. Now when you receive email from that person you know that it is the person you talked to previously (as long as the key exchange is not compromised). Who cares what your real name is, or where you live, etc
Re: (Score:2)
Actually, I had to get a key pair from verisign for a previous employer who required my mileage forms to be submitted via signed email. But then verisign dropped their free basic email keys so I had to move to comodo. (are there any better/other free options?)
Re: (Score:2, Interesting)
Unfortunately, this doesn't entirely fix the issue. Diginotar has certificates that have been cross-signed, meaning they can be used as intermediates in a chain rooted by another CA.
Re: (Score:2)
A larger problem is that all the certs that are delivered in Firefox are hard coded (will come back as soon as you quit + relaunch firefox) and have been multiplying.
This more than anything else is pushing me to abandon firefox for Chrome which has many fewer cert authorities that I see no reason to trust.
Comodo has already proven themselves to be insufficiently competent. Now why the hell should I trust Turktrust?? Hong Kong Post?!? Chungwa Telecom?!? CNNIC?!?
This makes it worse! (Score:2)
Re: (Score:2)
Or better still: revoke their entire CA, and *don't* start a new one.
Re: (Score:2)
They need to not just dump every single private key, but do it the right way, and use hardware security modules that limit access, and what access is granted is thoroughly logged.
RedHat had a break-in a few years back with a blackhat getting access. The attack was mitigated of in a matter of hours, and the damage was very limited (with "blacklist" keys sent out for the rogue packages that were signed.) A CA has to have their core keys in a HSM, or they should not be in business because their whole commerc
Re: (Score:3)
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?
The way I hear the quote from the summary
On July 19th 2011, DigiNotar detected an intrusion into its Certificate Authority (CA) infrastructure
is "We found out this week that fraudulent certificates were issued on July 19th..."
Can someone explain... (Score:2)
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.
Re: (Score:2)
The chain-of-trust model is not hierarchical. Many CA certificates do not include a domain name at all. It is all about the certificate subject and the key usage flags.
Re: (Score:2)
> Can someone explain why a .nl organization has the .com certs?
> power to produce
To avoid having a monopoly in the CA space?
But yes, having some limits on what CAs are trusted to issue certs of which sites what is a good idea, and I fully expect browsers will move in that direction. I'm certainly pushing for it.
Re: (Score:2)
Heh, good catch. .cn is what my 30-something brain meant.
Re: (Score:2)
Great explanation, thanks, but I disagree this is essentially about trust. Sure, my CA is trustworthy today, but if there's some exploit on our network and tomorrow the internet is flooded with fake certs.
You can't trust entities, you can only trust components. I think CA's in general are just security through obscurity and don't provide any real security. A determined attacker just finds a way to generate a SSL from a compromised CA or uses laws like the PATRIOT ACT to generate one from a CA.
Crazy Response to Attack (Score:3)
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.
Re: (Score:2)
Right and while we're at it, they should be subject to random security audits. Given that the signing key doesn't need to be present on a network to work, I'm not really sure I understand how a breach like this couldn't have been prevented.
Re: (Score:2)
Debian has /usr/sbin/update-ca-certificates that reads certificate configuration from /etc/ca-certificates.conf and generates the certificate store for any applications that use the mechanism, which includes openssl, Firefox, and Java as installed from the Debian repositories.
I would think it would be easy to write a program that does the CRL checking as you described and remove the entries from /etc/ca-certificates.conf.
Re: (Score:3)
I disagree. I trust public CAs for web browsing. I trust my company CAs for company email.
The reverse of this is not true.
TBH, we should have certificate stores for each application. In a perfect world, I should install my bank's certificate as a trusted certificate, and distrust Thawte, Verisign, etc when visiting mybank.com. But alas, that is hard.
Re: (Score:2)
Already done. https://www.ironkey.com/trusted-access [ironkey.com]
Apparently even protects against man-in-the-middle attacks and keyloggers.
Re: (Score:2)
AFAIK, the lists are part of the SSL libraries I think. Two of the commonly used ones are Mozilla's NSS and MS's SChannel.
Re: (Score:2)
And I forgot to mention that SChannel, while most often used by IE, is actually part of Windows itself.
Re: (Score:2)
Chrome on Windows also uses the Windows Certificate Store.
Re: (Score:2)
Only that it doesn't work, or maybe I did something wrong.
I started the Keychain utility app, searched for the Diginotar certificate and set its trust setting to Never Trust. Then I opened Diginotar's test page in Safari and there was no notice whatsoever. Only after removing the certificate did I get a warning.
Re: (Score:2)
Yeah, that is how it works in Windows, when using Microsoft software (like Internet Explorer).
The list of trusted roots is completely separate from the browser code.
But I guess that is not popular to say here...
Which also means you can't control which CAs are trusted from IE. You wait for Windows Update to do it for you. That's probably the right thing to do for most people.
Re: (Score:2)
Actually, in versions after Windows 2003 this does not use Windows Update but a separate service for updating the list of trusted roots.
(XP and 2003 use an optional update sent via Windows Update)
Microsoft can revoke root certificates without making their customers update to a new version of the browser.
Other browsers are lacking in this respect.
So instead of having to trust CAs we just have to trust MS? This is a lack?
Re: (Score:2)
Re: (Score:2)
Iran is excluded because they're not to be trusted. The real question is why we trust the Israelis and some of the other folks we trust.
To whom it make concern: (Score:5, Insightful)
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...
Re: (Score:2)
I also find it quite disgusting how they mainly focus on the damages potentially being done to their own company and the profits it might or might not generate, instead of considering the damages done to others, in this case even to individuals that may pay for this incident with their lives.
Root certs need to be restricted by TLD (Score:5, Insightful)
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 [cabforum.org], from which a penalty is forfeited if any improperly issued cert is found. That should get the problem under control.
Re: (Score:2)
Why only one CA per certificate? (Score:2)
Could one not send CSRs to more than one CA and the browser indicates how many CAs responded ok?
Too late (Score:5, Informative)
Re: (Score:2)
As you should, them revoking the certificate wouldn't do you any good until your browser Firefox gets an update which contains the revoked certificate information. Certificate revokation doesn't automatically propegate to all users.
Re: (Score:2)
Re: (Score:3)
http://support.mozilla.com/en-US/kb/deleting-diginotar-ca-cert [mozilla.com]
this makes me happy (Score:2)
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
F-Secure article on this (Score:2)
http://www.f-secure.com/weblog/archives/00002228.html [f-secure.com]
Re: (Score:2)
Mod parent up please!
Wow, just Wow, Diginotar appears to have been hacked a loong time ago & is only now discovering it!
In MacOSX (Score:5, Informative)
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 [diginotar.nl] to ensure that the trust is broken.
Wouldn't secure DNS solve a good portion of this? (Score:2)
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
Why do CAs even exist? (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 ver
Re: (Score:2)
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.
Re: (Score:2)
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.