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 "After previously claiming that the Iranian hack of CA Diginotar did not compromise certificates of the Dutch government, it has now been decided that there is too much risk and the certificates will have to be revoked after all (original Dutch text). Since the Dutch government has been using only Diginotar-supplied certificates, this will leave all government websites with invalid certificates while a new supplier is being searched for. The minister of internal affairs recommends people not to use the websites if a warning about an invalid certificate appears." Related: Reader TheAppalasian links to Johnathan Nightingale of Mozilla Engineering explaining in clear terms why DigiNotar should no longer be trusted.

But there are a *lot* of sites. A lot of municipalities use certificates issues by Diginotar as well.

Big deal. Certs are renewed every year or two anyway. All they need to do is call up whoever handles that sort of thing and get a new cert. If your local municipality doesn't have SSL for a day or two it's hardly a major disaster. Replacing a cert is very easy. I'll bet there's a million people around the world that could do it in a pinch, myself included.

Relying on genuine certificates is not insecure. Revoking genuine certificates solves nothing. If someone's browser is relying on the genuine government certificates issued by Diginotar, then there is no security vulnerability with that particular communication, regardless of anything that happened at Diginotar. If somebody is fed a bogus certificate issued by Diginotar, and their browser relies on the bogus certificate, then revoking the genuine government certificates won't help.

I was mistaken above. Pe1chl explained below that it was the Dutch Government that acted as certificate authority and issued an intermediate certificate to DigiNotar, which used the intermediate certificate to issue certificates to various government agencies. The government needs to revoke the intermediate certificate it issued to DigiNotar and thus invalidate all the government certificates issued under it.

You obviously have no clue of all the steps involved...Most sites are hosted externally, usually with 2-3 parties involved per site. You need to go through all those hosters change / support systems, which might take hours but can also easily take days (if not weeks....) Add in that it's still holiday season, the fact that the severity of the incident means that many politicians and public servants will want to have their piece of the actions and you have a recipe for a longwinded mess.

Most sites are hosted externally, usually with 2-3 parties involved per site. You need to go through all those hosters change / support systems, which might take hours but can also easily take days (if not weeks....)

Oh well. Now they pay the price of making something that's a few hours work into a game of telephone tag.

I actually don't really agree with you. No matter how much administrative gobbledygook you stack on top of each other, ultimately there's one, maybe two people per site that will actually d

Every big city has between like 5 and over a 100 websites, of which almost 50% nowadays uses SSL (which by itself is a good thing!) Things like social housing, requesting a new passport/drivers license, every city has their own website(s) and almost all are secured by SSL as all those things involve personal data.

I used to work for a big hosting company who hosted stuff for many bigger cities. I remember Amsterdam having over 4 dozen websites just running at our company, linked

If you haven't been following this story, Gerv (one of the Mozilla people directly dealing with this) has a good overview post with something of a timeline [gerv.net], hitting all the salient points about just how much DigiNotar has fucked up.

The whole system of transitive trust is messed up. Fatally flawed at the foundation, promoted because certain large vendors of system software find the transitive trust concept easier to systemize and monetize than the way it should really work.

(Every system has vulnerabilities. It's a feature of systems in general, not just software or information systems.)

You can't really trust anyone you don't know, and that's the real problem with the current state of the computer/information systems industries. It's al

I believe the Dutch government was saying "Since most users don't pay attention to the protocol (https) or the lock somewhere on their browser screen on sites or pages that require a secure connection they shouldn't use any sites that give them a warning about the certificates. Any other sites or pages that do not require a secure connection (most of their sites and pages) are safe to use."

The only reasonable action is to take the sites down until a valid certificate has been issued and installed.

You are correct. Taking down any sites or pages that require secure connections is the only way to protect site visitor

This was probably mainly said because DigiNotar itself publishes a FAQ that basically says "when the browser says the certificate is not to be trusted you must select the option to trust it anyway because 99.9% of the certifcates are to be trusted".The Dutch government wants to warn citizens that this is very bad advise from DigiNotar, and that sites should never be used when this warning appears.In fact there is a campaign from banks to warn users that they should always take attention to certificate warnings, and any official advise to ignore them is to be considered a very bad thing.

Of course DigiNotar does not understand "trust" at all. In their FAQ and press releases they apparently have the opinion that trust in the certificates is something they define themselves, while of course trust is something the user grants to the CA. When the user no longer trusts the CA, the CA is finished no matter how many times it declares that it is to be trusted.

But DigiNotar is not interested in the users or the victims of their actions. They are only interested in their own company and its revenues. This was already clear in the first press release they did, where they dared to include a paragraph that downplayed the effect of all this on their revenue and share value.Let's see how this works out in practice. My prediction is that it will be worse than they claim.

And this example is exactly why I've configured firefox to Not trust any root level certificate. Yes it's a bit of a PITA for those sites that use SSL/Https but I also find that the number of exceptions I've had to issue so far has been less then 30 since Jan 1, 2011. We're now into the 9th month (3rd Qtr) and I've only had to issue >30 exceptions to the non trusted status and that shows just how piss poor our net security really is.

This is not at all correct.DigiNotar has its own root certificate and it was removed from the browsers this week, but this is not related to the Dutch government.The Dutch state has its own trusted root certificate (a bad thing in its own right!) under which there are a couple of subordinate certifcates, under which there is an intermediate certificate issued to DigiNotar, and that certificate is used to sign the server certificates for the governmental sites.Only that last level was managed by DigiNotar, a

The whole point of this last update to the story is that the Dutch government no longer trusts the DigiNotar intermediate and is revoking it. Browsers are also shipping updates to revoke the DigiNotar intermediate.

So in fact, the Dutch Government website certs are now invalid or will become so very soon in browsers.

To revoke the DigiNotar intermediate, a browser that has OCSP or CRL does not need an update. At least if it is formally revoked by Dutch state (which it isn't, AFAIK).

The updates are only required for root certificate revocations, apparently there is no OCSP or CRL for those (something that should be fixed).But Mozilla is not distrusting the certificates based on revocation, but guided by the "CN=DigiNotar" in their issuer field.That is why they need to upgrade the code.

As long as you're wiling to accept that a DoS of DigiNotar's OCSP server will mean certs remain valid, sure.

Now browsers could treat failure to connect to the OCSP server as fatal, but it turns out lots of CAs run very flaky OCSP server, so if this were done SSL connection failures would be very common. It'd be nice to get to a state where that's not the case, but it hasn't happened yet.

The revocation of certain certificates hasn't been as comprehensive as originally stated, before this point. SANS did a good write-up of this, where they dug into the details of the CRL updates and update history to try and figure out exactly what happened when with revocation, and they couldn't find evidence of a lot of the claimed revocations. In my opinion, this demonstrates an underlying problem with the architecture of PKI as it exists today, and how revocation of trust works...in the name of reliabi

Entrust cross-certified CNNIC as well, and not only they haven't been distrusted for doing so, but CNNIC has been promoted as a root as its own.

If an organization with a history of widespread MITM attacks gets to become a CA, you can see how little trust you can put in the system in general.

The argument for not removing CNNIC from Mozilla is that none of their documented attacks involved SSL. If you rob jewelers, you should be trusted to repair a bank safe, right? And a similar case with Etisalat proved t

Yup. SSL is really messed up. The best fix would be to just put certs in DNS and protect it with DNSSEC. Then you have a hierarchical system for managing them that doesn't cost anything that people aren't already paying. You could still allow for CAs when you need to add some level of real-world identification, or maybe the domain registries could provide this service (so it would be an attribute of the domain one level higher). However, the main threat is from MITM and domain-only checks are generally

Apple is behind the curve on this, almost certainly due to a bug in the handling of Extended Validation certificates that needs to be fixed. Until then, I have info and tools on my web page to help users with the problem.

Yeah, it's super hard in windows...http://www.microsoft.com/technet/security/advisory/2607712.mspx [microsoft.com]
All supported editions of Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 use the Microsoft Certificate Trust List to validate the trust of a certificate authority. There is no action required for users of these operating systems because Microsoft has removed the DigiNotar root certificate from the Microsoft Certificate Trust List.

Shouldn't MS be releasing a hot fix to remove these bad certificates in XP SP3's IE versions with a hot fix or something? I had two of them in mine. I didn't check Windows 2000 SP4 machines. I assume they have them.

They should, but they haven't done that yet.There is a security bulletin 2607712 that explains what they did for Vista and newer, but for XP and 2003 they should release a new version of rootsupd.exe that will update the list of root certificates.This is not an update to IE but to a separate Windows component that stores the root certificates.

These instructions should be on every Dutch government website, and on many others besides (community spirit). The browsers themselves (IE, Firefox, Chrome, Opera, etc) should release upgrades with the root cert deleted.

And all of this should be automatic. Diginotar should pay the cost, or their insurer should. Or the Dutch government should, if it's going to create the exposure to this risk by elevating Diginotar to this critical role.

"The minister of internal affairs recommends people not to use the websites if a warning about an invalid certificate appears."
While that is basically good advice, it suggests that it is okay to use the websites as long as the warnings are not appearing yet.
Most browsers still trust the CA, but that doesn't mean that the CA is trustworthy.
He should have recommended not to use the websites as long as they are still using Diginotar certificates.

There's a much bigger problem here, why trust ANY certificate anymore? Who's to say other certificateproviders haven't been breached? this one happened to be discovered, but I'm pretty sure it isn't the only provider that was comprimised..

Since the Dutch government has been using only Diginotar-supplied certificates, this will leave all government websites with invalid certificates while a new supplier is being searched for.

The government should never have had a single point of failure waiting to fail. There should have been at least a second, and probably also a third (instead of creating a new SPF at #2) , source of certificates, at least ready to replace Diginotard (not a typo:P) when it failed. There should now absolutely be a backup s

Three days those sites can't operate. The whole point is that standard procedure should have backup CAs for precisely this risk. Or what if Diginotar just went out of business?

The vetting process should be operated beforehand, and ongoing if necessary. That's what single points of failure are about. The Dutch people deserver better. But if the Dutch government agrees with your post, they'll be stuck with the crap they've got. For the next time - maybe next week, maybe next month. but sooner than later.

If certificates could have multiple signers, we could nix the authority of any one CA and still keep the cert.

An analogous change would be to enable multiple signatures on a single certificate. Recall that a single X.509 certificate contains a public key, a subject, and a signature binding the two together from a CA. There's no reason (in principle) that we couldn't declare a certificate as a public key, a subject, and a set of signatures, each from a different CA. It turns out that there is a proposal for this kind of alternate, multi-signature certificate (using the OpenPGP standard), which i'll talk about later.

I mentioned earlier that there is an alternate proposal — OpenPGP Certificates instead of X.509 certificates [ietf.org] — which allows multiple signatures per certificate. The proposal is designed to be implementable in parallel with existing X.509 certificates. However, it is not widely implemented or adopted yet.

Cross-signed certificates exist right now. It's completely standard practice in many cases. In particular when a new CA starts, it often cross-signs all its stuff with existing CAs for a bit so that its customers have working certs even when dealing with clients who have never heard of the new CA.

When you say "cross-signed certificate", do you mean website certificates where more than one CA has signed them? I'd thought "cross-signed" or "bridge" certificates were like CA certificates in that they sat in your browser and linked CAs. If that's the case, that's different in a way that doesn't get you the aforementioned value from having multiple CAs sign a single web certificate independently.

I haven't seen website certs with multiple signers. If anyone knows for sure this is possible or has an example to share, please speak up.

Cross-signing IIUC is only when CAs authorize other CAs:

A cross-certificate is a certificate issued by one Certificate Authority (CA) that signs the public key for the root certificate of another Certificate Authority. Cross-certificates provide a means to create a chain of trust from a single, trusted, root CA to multiple other CAs.

(Note, I believe you can sign a CA's intermediate instead of their root; this appears to be what happened with the DigiNotar incident.)

Various DigiNotar intermediate certificates had been cross-signed by other trusted CAs. In order to achieve full blocking, we implemented code which checks for DigiNotar's name in the certificate chain.

It's impossible for a reasonable person to go through the list and verify whether any individual one is really necessary or not. Conversely, it's far too difficult for most people to add a CA they need, but which shouldn't be globally trusted. One which primarily serves Dutch users definitely belongs in the latter category. There's no reason for a Californian to automatically trust them.

As for any CA which has any breach whatsoever, the only responsible thing for anyone who maintains a list of trusted CAs i

It's not that Diginotar can no longer be trusted, it's that they never should have been trusted at all. Clearly their security was faulty and moreover, someone in management over there had the gall to try to cover up the security breach. The for this should be obvious - they have a vested interest in appearing secure, even if they aren't.

How long until we find the same is true for virtually every CA in the world?