Dutch Government Revokes Diginotar Certificates 78
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.
Thank goodness it is not tax season (Score:4, Insightful)
Since we have to use the sites to send in our digital tax forms, that would have been a way bigger mess.
Re: (Score:1)
yes, those paper forms suck. :)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
There are client certificates in use for some gov related sites. These have to be reissued in a secure way.
Revoking Dutch Gov certificates is pointless (Score:2)
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.
Of course it is necessary
Re:Revoking Dutch Gov certs is NOTpointless (Score:2)
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.
Re: (Score:1)
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.
With cert renewal you
Re: (Score:2)
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
Re: (Score:1)
Obviously you're not Dutch...
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
Overview (Score:5, Informative)
messed up? (Score:2)
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
Re: (Score:2)
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
Re:Crypto is hard (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
What you say is _mostly_ correct.
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.
Re: (Score:2)
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.
In fact it is ugly, hardcoded excep
Re: (Score:2)
> a browser that has OCSP or CRL does not need an
> update
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.
CRLs, of course, have the obvious issue where if you DoS t
Who cares? (Score:1)
Does anyone even look at the certs? I consider them worthless, and ignore them 100% of the time.
Re: (Score:2)
I have looked at them when using an anonymous SSL proxy to access a UK restricted webshop, to make sure the proxy wasn't MIM'ing me.
Another reason not stated by Mozilla... (Score:2)
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
Re: (Score:2)
Browsers nowadays use the OCSP [wikipedia.org], which is queried dynamically. The problem is that Mozilla doesn't trust Diginotar at all.
Re: (Score:2)
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
Re: (Score:3)
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
For Mac Users (Score:3)
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.
http://ps-enable.com/articles/diginotar-revoke-trust [ps-enable.com]
--Paul
Untrust Diginotar (Score:2)
At this point, everyone should remove the trust for the Diginotar Root CA. I guess most people know how to do this around here, but just for informative purposes:
First, visit their web site to ensure their root certificate is in your certificate store:
https://onlineaanvraag.diginotar.nl/Digiforms/StartPage.aspx?FORM_ID=12 [diginotar.nl]
On Mac OS X go to Applications, Utilities, open Keychain Access. Click on System Roots, then find the "Diginotar Root CA". Select it then do CMD-I. Open the Trust Panel and choose "When usi
Re:Untrust Diginotar (Score:4, Informative)
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.
I don't have an XP box here to look at, but I'm pretty sure you can get to the Trusted Root Cert Authorities by going IE >Internet Options > Content > Certificates > Trusted Root Cert Authorities, doubleclick DigiNotar and uncheck all.
Re: (Score:2)
Interesting, it was still trusted on my Win7 box.
I just checked another machine here also running Win7 and that certificate is not trusted on it.
Re: (Score:1)
Don't forget that the automatic untrusting in Windows doesn't affect browsers with their own CRLs which ignore the OS, like, err, Chrome and Mozilla, those needed to be updated separately.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Ah. I wonder why they didn't release an emergency hotfix like Mozilla and others. :(
Re: (Score:2)
What about in Ubuntu? MacOS? Android for mobiles?
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.
And of course the Dutch
Re: (Score:2)
Mozilla already released updates to Firefox (3.6.21 and 6.0.1) to distrusts all DigiNotar certificates.
Test here: https://www.diginotar.nl/ [diginotar.nl]
Firefox: sec_error_revoked_certificate
Re: (Score:2)
What test result shows the cert is successfully revoked? What test result shows fail?
Re: (Score:2)
If it is revoked, you get a "sec_error_revoked_certificate" error.
If it isn't, the page loads normally.
Re: (Score:2)
Thank you very much.
Re: (Score:2)
The usual secure site padlock means failure, anything else means their certs are dead to you.
Re: (Score:2)
Care to post a link? AFAICT every page currently redirects to http.
Re: (Score:2)
Android for mobiles. How quaint. :)
Uh, good luck there. Start with rooting your phone, or praying that your carrier pushes out an update. While you're at it star this bug [google.com].
Strange advice from the minister (Score:1)
Change domain names (Score:2)
Should we really trust revocation of certificates?
It might make more sense to change domain names than to trust that the bogus certificates won't be used.
revolution (Score:2)
I guess the system is pretty fucked up if this is a valid concern.
hmmm.. (Score:1)
Re: (Score:1)
Why? Because, if you think about it, that's an unrealistic, unhelpful and an undesirable alternative.
Single Point of National Failure (Score:2)
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
Re: (Score:2)
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.
multiple signers (Score:2)
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.
http://lair.fifthhorseman.net/~dkg/tls-centralization/ [fifthhorseman.net]
That is, if we're bothering with CAs in the future, instead of notaries (e.g. Perspectives or Convergence) or some other technology.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
> do you mean website certificates where more than
> one CA has signed them?
That's what I was talking about, yes. I'm not aware offhand of anything preventing such, and I was under the impression that they were in fact used in various cases.
But yes, one CA signing another CAs certificate is the more common way that sort of thing is done.
Re: (Score:2)
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.)
Re: (Score:2)
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.
http://blog.gerv.net/2011/09/diginotar-compromise/ [gerv.net]
Implemented code to compensate for the DigiNotar chaining?
Stark example of how the current model is well and truly fucked.
There are far too many CAs (Score:2)
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
Never should have been trusted in the first place (Score:2)
How long until we find the same is true for virtually every CA in the world?