Slashdot Mirror
Dutch Government Revokes Diginotar Certificates
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.
Since we have to use the sites to send in our digital tax forms, that would have been a way bigger mess.
This is the sig that says NI (again)
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, hitting all the salient points about just how much DigiNotar has fucked up.
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 reliability, the trend is for trust to continue, and any certificates from a trusted root provider are "innocent until proven guilty." This is a terrible model to employ if you have even one untrustworthy (either by choice, or by failure to implement effective security) root provider. Thus, any failure by a root provider that takes place on this scale, particularly where unknown numbers of intermediate certificates have been fraudulently issued without any real ability to track which ones they are, should result in a PKI death penalty. The only way to be sure that the damage is contained and stopped is to terminate trust of the entire root of that CA authority.
For your security, this post has been encrypted with ROT-13, twice.
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 visitors.
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
--Paul
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
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 using this Certificate Never Trust" instead of System Defaults. Close the window, enter an admin password and close Keychain Access.
On Windows it's a bit more complex (no, really?). Start, Run, mmc.exe, OK. Confirm UAC if under Windows 7 with admin password if required. If you're under Windows XP, relog to an administrator account first. Then go to File, Add/Remove Snap-in, find the Certificates snap-in, click on it, then add. Select the Computer Account and local computer. Then open Trusted Root Certification Authorities, Certificates, find the "DigiNotar Root CA", right-click on it, properties and choose "Disable all purposes for this certificate".
Make sure you don't delete the certificate, as it would just get re-approved.
If he explores all forms and substances Straight homeward to their symbol-essences; He shall not die.
"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.
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.
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, and the certificate used by them could be revoked and all server certificates would become invalid.
However, that was not done. The warning about security messages is only given because some browser vendors may ship updates that deem everything signed by DigiNotar untrusted, independent of the certificate tree above it.
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.
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..
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 source of certificates available (and a #2, and a #3), hotswappable. I'd like to think the Dutch government (and all governments) learned this lesson from this failure, but I expect we'll see the SPF architecture reinstalled with the new certificates.
--
make install -not war
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.
I guess the system is pretty fucked up if this is a valid concern.
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 for browsers to revoke trust in all Diginotar issued certificates. So all the government certificates issued by Diginotar are effectively revoked, regardless of any government action, for anyone using a browser that has stopped trusting Diginotar.
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 — 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/
That is, if we're bothering with CAs in the future, instead of notaries (e.g. Perspectives or Convergence) or some other technology.
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.
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 is to immediately and permanently remove them. They are expendable.
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.
Mod me up/Mod me down: I wont frown as I've no crown
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 also the reason why the methods of developing Linux and the BSDs are the correct methods of developing software. (As opposed to what the "traditional" companies do.)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
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.
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?
The right to protest the State is more sacred than the State.
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 exceptions for specific mishaps are being added to the software.
Something should be done that enables control of this kind of mishaps without having to update the software.
E.g. at work we have a Mozilla Seamonkey 2.0 deployment that I cannot yet upgrade to 2.3 because of bugs in that version and there are
no updates to 2.0 released anymore. Of course OCSP is enabled, but it would be better if it also worked for root certificates.
> 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 the server the CRL comes from the browser just has no way to know when things are added to the CRL.
> But Mozilla is not distrusting the certificates based
> on revocation
Oh, it's distrusting them based on revocation too. But the fact is, revocation is broken in the face of a MITM who can control whether packets reach the OCSP and CRL servers. So an additional explicit check is being added to the software too. Of course if the MITM is blocking browser update downloads as well the users still lose... but at that point maybe they might at least _know_ they have lost, because they realize the browser update is being blocked. Maybe.
> Something should be done that enables control of
> this kind of mishaps without having to update the
> software.
The only way to do that with the current PKI setup is to have something like OCSP for all certificates, with a hard-fail on failure to connect to the OCSP server. Which is somewhat difficult given the current state of internet infrastructure.