Slashdot Mirror

← Back to Stories (view on slashdot.org)

Dutch Government Revokes Diginotar Certificates

Posted by timothy on from the now-you've-done-it dept.

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.

78 comments

  1. Thank goodness it is not tax season by Killjoy_NL · · Score: 3, Insightful

    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)
    1. Re:Thank goodness it is not tax season by todorb · · Score: 1

      yes, those paper forms suck. :)

    2. Re:Thank goodness it is not tax season by Anonymous Coward · · Score: 0

      Your country still allows paper tax return submission? How quaint!

    3. Re:Thank goodness it is not tax season by Anonymous Coward · · Score: 0

      I guess that's why they waited so long; we normally have to file taxes before april 1st, but you also file a request to postpone that to september 1st.

      It would have become a serious mess if they didn't have a valid certificate on the last few days of august.

    4. Re:Thank goodness it is not tax season by Anonymous Coward · · Score: 0

      What paper forms? For most forms the Dutch government demands people use an electronic form. In fact, for a lot of them there is no paper equivalent anymore.

    5. Re:Thank goodness it is not tax season by Co0Ps · · Score: 1

      Meh. I think the dutch government can get a certificate validated pretty quickly and installing a new certificate should take a couple of hours at most anyway.

    6. Re:Thank goodness it is not tax season by lhuiz · · Score: 1

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

    7. Re:Thank goodness it is not tax season by Vellmont · · Score: 1


      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.

      --
      AccountKiller
    8. Re:Thank goodness it is not tax season by kwark · · Score: 1

      There are client certificates in use for some gov related sites. These have to be reissued in a secure way.

    9. Re:Thank goodness it is not tax season by javanree · · 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 can plan for this and if you start on time nobody notices anything. This however is totally unplanned and I would be VERY surprised if they manage to fix all sites within a week.

    10. Re:Thank goodness it is not tax season by Vellmont · · Score: 1


      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 do the work. If it's that big a deal, and a major site, with major inconveniences it just takes a few phone calls to the right people to get things done. Apply the right pressure to the right people, and things can get done rather quickly. How many sites really need SSL anyway? Does every little town in the Netherlands have an e-commerce site where people pay water bills, or renew car registration? If that's the case, that's a much larger waste than this silly SSL cert thing.

      --
      AccountKiller
    11. Re:Thank goodness it is not tax season by javanree · · 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 to hundreds of URL's, most of them equipped with SSL.

      Getting a new certificate meant going through the proper chain of authorities... most of the people involved were government employed and (thus) not always well motived and sometimes just clueless as to the urgency. I've seen things like this take weeks. It's not like they actually let the two technical people on both ends just do their jobs, that's WAY too simple. You'll encounter probably half a dozen of auditing/managing layers at least.

      Some cities at least were smart enough to get wildcard certs... which make these things a lot easier.

      Is it a waiste? Dunno, don't really care either. The more I learned about our government's IT, the less I trust it. So I do everything the old-fashioned way by paper and snail-mail.

    12. Re:Thank goodness it is not tax season by Anonymous Coward · · Score: 0

      So if the Dutch government use DigiNotar's certificates, who operates the Staat der Nederlanden certificates in Firefox's default certificate list?

      Or are they there so the Dutch can issue their own Google certs too?

    13. Re:Thank goodness it is not tax season by Anonymous Coward · · Score: 0

      They have already deployed new certificates for DigID from Getronics. The business part of the tax site uses a Verisign certificate. phew...

  2. Overview by Anonymous Coward · · Score: 5, Informative

    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.

  3. Crypto is hard by Anonymous Coward · · Score: 0

    So the recommendation is not to use the web sites if an "invalid certificate" warning appears. I would suggest to be cautious when no such warning appears, as there should currently be no way to get to these sites without seeing a warning, considering that the certificate has been revoked. The only reasonable action is to take the sites down until a valid certificate has been issued and installed.

    1. Re:Crypto is hard by WrongSizeGlass · · Score: 1
      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 visitors.

    2. Re:Crypto is hard by Anonymous Coward · · Score: 0

      Also, revoking the issued certificates is pointless, because that doesn't do anything about other certificates for the same sites that may have been issued to / created by the hackers. Revoking certificates is what you do when the corresponding private key has been compromised. Unless the Dutch government has accepted a private key generated by Diginotar, which would be a major fuckup in its own right, the official web site certificates don't need to be revoked. Trust placed in Diginotar's CA certificate is the problem: The Dutch government can't revoke that certificate because Diginotar is a root CA that is directly trusted by browsers and operating systems (well, used to be trusted). Since Diginotar has been compromised, it is possible that they can't revoke all certificates, because they may not even know about all of them. The only way to ensure that no malicious certificates issued by the Diginotar CA are usable in the wild is to distrust the Diginotar CA itself, not just a list of "all" certificates issued in the past. Diginotar is dead.

    3. Re:Crypto is hard by pe1chl · · Score: 1

      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.

    4. Re:Crypto is hard by pe1chl · · 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.

    5. Re:Crypto is hard by fast+turtle · · Score: 1

      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
    6. Re:Crypto is hard by BZ · · Score: 1

      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.

    7. Re:Crypto is hard by pe1chl · · Score: 1

      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.

    8. Re:Crypto is hard by BZ · · Score: 1

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

  4. Who cares? by Maury+Markowitz · · Score: 0

    Does anyone even look at the certs? I consider them worthless, and ignore them 100% of the time.

    1. Re:Who cares? by Anonymous Coward · · Score: 0

      The whole point of the certificate authority system is that you don't have to look at the certificates, because someone else, whom you trust, has made sure not to issue fraudulent certificates. When your trust in the CAs is violated, you end up with problems like the current ones: You can't rectify the situation without revoking trust in that CA certificate, but when you do that, you instantly leave thousands of web sites without valid certificates.

    2. Re:Who cares? by Pinky's+Brain · · Score: 1

      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.

  5. Another reason not stated by Mozilla... by Shoten · · Score: 1

    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.
    1. Re:Another reason not stated by Mozilla... by Anonymous Coward · · Score: 0

      I've always found it odd that every Root CA cert under the sun is shipped with browsers and the like, but don't include any CRL's to go with them. I'm mean, that whole purpose of CRL's, right? If a CA finds a fraudulent cert, it revokes the cert and the browser checking for CRL's of that CA will then untrust the cert. Isn't that how it's supposed to work? It just seems ludicrous that you have to update your application with a hardcoded blacklist of certs and CA's everytime there's a CA compromise published in the news.

    2. Re:Another reason not stated by Mozilla... by Anonymous Coward · · Score: 0

      Why isn't anybody questioning how Diginotar was given a cross-cert and thus trust in the first place? Doesn't that blame fall on Entrust who cross-certified them?

    3. Re:Another reason not stated by Mozilla... by icebraining · · Score: 1

      Browsers nowadays use the OCSP, which is queried dynamically. The problem is that Mozilla doesn't trust Diginotar at all.

      --
      Dilbert RSS feed
    4. Re:Another reason not stated by Mozilla... by KiloByte · · Score: 1

      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 that knowingly signing malware is not enough to be kicked off, either.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    5. Re:Another reason not stated by Mozilla... by Rich0 · · Score: 2

      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 good-enough for that.

      But, if we have to stick with the current system if I were a browser vendor I'd:

      1. Include a CRL in my app for the root CAs. I'd control that CRL. So, when I need to revoke a root cert I just publish that on the CRL and I don't need to hard-code it in some kind of software upgrade.

      2. My browser would fail-safe on CRLs. The CRL would have to publish a new serial number hourly. The browser would cache the last serial number seen. Every cert is checked at time of access, and if the CRL doesn't respond or gives me an expired serial number or anything else that is fishy then the cert is considered revoked. Sure, that is a pain, but right now you just need to block access to a CRL and browsers just dumbly go along with it. The browser would also cache system time in GMT and ask the user what to do if it jumps backwards to reduce the risk of clock attacks.

      The whole system just needs to be a lot more paranoid. With the current design that would also make it a lot less reliable. The fix to that is to just use DNSSEC - if you can't look up the DNS record for a host you're not going to connect to it anyway.

  6. Be Careful by Anonymous Coward · · Score: 0

    These kind of hack increased these days.

    Buy Facebook Zynga Poker Chips
    http://www.socialplayful.com

  7. For Mac Users by plsuh · · Score: 2

    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

  8. Untrust Diginotar by jeffasselin · · Score: 1

    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.
    1. Re:Untrust Diginotar by iceperson · · Score: 3, Informative

      Yeah, it's super hard in windows...
      http://www.microsoft.com/technet/security/advisory/2607712.mspx
      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.

    2. Re:Untrust Diginotar by jeffasselin · · Score: 1

      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.

      --
      If he explores all forms and substances Straight homeward to their symbol-essences; He shall not die.
    3. Re:Untrust Diginotar by Doc+Ruby · · Score: 1

      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 government should extract the cost of the damages from the damagers. If it can't actually catch the people who did it, because their foreign government doesn't support that kind of criminal prosecution, the Dutch government should tax all trade with that country until it's paid - including the cost of damages from implementing the criminal prosecutions and administering the tax. If the foreign government is directly out of reach, tax the trade with other countries that do trade with the "safe harbor" foreign government.

      You can't just attack a significant global political/commercial power like this and not pay the price. The Dutch government's response should be severely punitive of the culprits and their associates, while aggressively proactive in removing the damage from everyone's critical path. A private corporation acting like crap when it's attacked is to be expected (even if to be punished), but a national government must act in the public interest, especially when it's created a threat to the public interest. An interest that stretches globally, not just for benefits during "normal business", but for damages at times like these.

      --

      --
      make install -not war

    4. Re:Untrust Diginotar by CyberDragon777 · · Score: 1

      Mozilla already released updates to Firefox (3.6.21 and 6.0.1) to distrusts all DigiNotar certificates.

      Test here: https://www.diginotar.nl/

      Firefox: sec_error_revoked_certificate

      --
      We both said a lot of things that you are going to regret.
    5. Re:Untrust Diginotar by Doc+Ruby · · Score: 1

      What test result shows the cert is successfully revoked? What test result shows fail?

      --

      --
      make install -not war

    6. Re:Untrust Diginotar by CyberDragon777 · · Score: 1

      If it is revoked, you get a "sec_error_revoked_certificate" error.

      If it isn't, the page loads normally.

      --
      We both said a lot of things that you are going to regret.
    7. Re:Untrust Diginotar by blowdart · · 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.

    8. Re:Untrust Diginotar by Anonymous Coward · · Score: 0

      That link redirects me to http. I clicked around until I landed on https and yep, it's untrusted now in FF.

    9. Re:Untrust Diginotar by Anonymous Coward · · Score: 0

      The clowns currently redirect their https pages to use http.
      Yes, really.

    10. Re:Untrust Diginotar by Anonymous Coward · · Score: 0

      First time I clicked on the link:
      Kaspersky Internet Security asked if I want to see .nl domain website. Clicked yes.
      FF (6.0.1) showed Diginotar's website.
      Certificate Patrol showed that the cert from diginotar has been accepted. I clicked reject.

      Then I went into FF Options->Advanced->Encryption->Validation and checked the box that says if connection to OCSP server fails then treat cert as invalid.

      Tried to go to above link again, this time it gave the error as above.

    11. Re:Untrust Diginotar by Doc+Ruby · · Score: 1

      Thank you very much.

      --

      --
      make install -not war

    12. Re:Untrust Diginotar by he-sk · · Score: 1

      Care to post a link? AFAICT every page currently redirects to http.

      --
      Free Manning, jail Obama.
    13. Re:Untrust Diginotar by Anonymous Coward · · Score: 0

      The whole idea of trusting a certain party to issue certificates for *any* url is completely flawed. The idea of trusting these issuing parties is ridiculous.

      I have removed all rare & unkown issuing parties from my browser. I know this does not solve the problem as any root ca can be compromised... But the fact is that the CA's that I have left are the bigger one's (verisign, thawte, ...).

      IF one of these is compromised & WHEN they are compromised, that will be a wakeup call for the whole community. Until then, its all a joke. Security trough obscurity.

    14. Re:Untrust Diginotar by Rich0 · · Score: 1

      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.

    15. Re:Untrust Diginotar by sjames · · Score: 1

      The usual secure site padlock means failure, anything else means their certs are dead to you.

    16. Re:Untrust Diginotar by antdude · · Score: 1

      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.

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
    17. Re:Untrust Diginotar by pe1chl · · Score: 1

      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.

    18. Re:Untrust Diginotar by antdude · · Score: 1

      Ah. I wonder why they didn't release an emergency hotfix like Mozilla and others. :(

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  9. Strange advice from the minister by BartvW · · Score: 1

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

  10. Change domain names by crow · · Score: 1

    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.

    1. Re:Change domain names by Anonymous Coward · · Score: 0

      Yeah, maybe google could change it's domain name to google2.com or something like that ;)

  11. Not all Dutch government sites affected. by Anonymous Coward · · Score: 0

    The slashdot article is wrong: not _all_ Dutch government HTTPS sites are secured by Diginotar certs, for example https://mijn.belastingdienst.nl (Dutch tax revenue service) is signed by VeriSign.

    The most important service that _is_ affected is DigID, which allows Dutch citizens to authenticate with government websites online, and this does actually include authenticating for online submission of tax forms.

  12. hmmm.. by SuperDre · · Score: 1

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

    1. Re:hmmm.. by drougie · · Score: 1

      Why? Because, if you think about it, that's an unrealistic, unhelpful and an undesirable alternative.

      --
      Calling out bogus battery capacity claims.
    2. Re:hmmm.. by Anonymous Coward · · Score: 0

      This provider has experience in screwing things up royally that all the others don't. In the future (if it still has one), DigiNotar will want to put WAY more effort into doing things properly and securely. The other cert providers might not care just because any possible breaches are still unknown.

  13. Single Point of National Failure by Doc+Ruby · · Score: 1

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

    1. Re:Single Point of National Failure by Anonymous Coward · · Score: 0

      The original statement is wrong: there are three other CA's that are allowed to issue PKIOverheid certificates. Because of the vetting process, it may take some days before a web site has a new certificates, however. I am afraid having backup certificates is not standard procedure

    2. Re:Single Point of National Failure by Doc+Ruby · · Score: 1

      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.

      --

      --
      make install -not war

  14. revolution by Onymous+Coward · · Score: 1

    I guess the system is pretty fucked up if this is a valid concern.

  15. Revoking Dutch Gov certificates is pointless by mrcaseyj · · Score: 1

    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.

  16. multiple signers by Onymous+Coward · · Score: 1

    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.

    1. Re:multiple signers by BZ · · Score: 1

      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.

    2. Re:multiple signers by Onymous+Coward · · Score: 1

      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.

    3. Re:multiple signers by BZ · · Score: 1

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

    4. Re:multiple signers by Onymous+Coward · · Score: 1

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

    5. Re:multiple signers by Onymous+Coward · · Score: 1

      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/

      Implemented code to compensate for the DigiNotar chaining?

      Stark example of how the current model is well and truly fucked.

  17. Re:Revoking Dutch Gov certs is NOTpointless by mrcaseyj · · Score: 1

    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.

  18. There are far too many CAs by Rix · · Score: 1

    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.

  19. messed up? by reiisi · · Score: 1

    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.
  20. Never should have been trusted in the first place by andymadigan · · Score: 1

    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.
  21. Diginotar and the Iranian Government by Anonymous Coward · · Score: 0

    Compromised Diginotar certificates have been used by the Iranian security agencies to spy on internet activity in Iran for many months. Diginotar knew about it but remained silent for a long time at the expense of freedom activists lives and livelihood in Iran.

    Now there are unconfirmed reports by Iranian sources pointing to the possibility that these SSL compromises have in fact been the result of a cooperation between Diginotar or the Dutch government (or both) with the Iranian government's hacker and cyberspy apparatus called "Cyber Army"..

    This may sound unbelievable, but it is a quite common practice in the netherworld of "security" agencies all over the world.