Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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."

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.

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.

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.

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

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.

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.

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.

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

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 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.

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.

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.

What level of people directly employed by government do you consider optimal? Currently, in the US, it is 1 in 7 and moving to 1 in 6. That does not count people as employed if their income depends on government programs such as welfare, etc. You could count those people as employed by the government too, only they're specifically paid for not producing anything. So 6 in 7 people work to pay the salary of the other 1 in 7 who are employed directly by government. Do you think the optimal ratio is 1 in 2 peop

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!

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.

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.

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!

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].

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

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.

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?)

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.

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

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 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.

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.

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.

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.

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.

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.

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.

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 n

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...

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.

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.

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.

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

open/Applications/Utilities/Keychain Access.appClick on System RootsScroll down to DigiNotar Root CAClick the "i" icon, or select "Get Info CMD-I"Expand the "Trust" nodeFor 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.

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

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.

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.

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

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.