Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Security The Internet IT

Certificate Blunders May Mean the End For DigiNotar 128

Posted by timothy
from the web-of-trust-works-by-breaking dept.
Certificate Authority DigiNotar is having a rough time of it. dinscott writes with these words from Help Net Security: "After having its SSL and EVSSL certificates deemed untrustworthy by the most popular browsers, around 4200 qualified certificates — i.e. certificates used to create digital signatures — issued by the CA are currently in the process of being revoked and their holders notified of the fact by the Dutch independent post and telecommunication authority (OPTA). Starting from yesterday, OPTA has terminated the accreditation of DigiNotar as a certificate provider for 'qualified' certificates. The revocation of this accreditation also makes DigiNotar unqualified to issue certificates under the PKIoverheid CA."
This discussion has been archived. No new comments can be posted.

Certificate Blunders May Mean the End For DigiNotar

Comments Filter:
  • In other, unrelated news, a certificate authority was compromised and it's taken months before customers were able to protect themselves. Meanwhile, the government who profited from the breach continues to smile, wave, while Microsoft complies with its request to not invalidate its unethically-obtained certificates for its own citizens.

    What's not news and should be: Why the hell we're not moving to ipv6 and telling these corporations to eat a bag of dicks, and our privacy and security is not for sale anymor

    • I'm not sure the parent post should really be moderated up, as it is now, since it seems to be reasonably misinformed.

      Firstly, Microsoft has invalidated the cert (at least to my knowledge).

      Secondly, it is not at all clear how moving to ipv6 tells the corporations to eat a bag of dicks while informing them that our data is not for sale anymore. The concepts (ipv6, dicks, and our data) all seem mutually exclusive.

      • Re: (Score:2, Interesting)

        Firstly, Microsoft has invalidated the cert (at least to my knowledge).

        Your knowledge is incorrect [google.nl]. At the request of the Dutch government, Microsoft deliberately did NOT patch its systems from that country... until several weeks later when the government's request was made public and they retracted their request.

        Secondly, it is not at all clear how moving to ipv6 tells the corporations to eat a bag of dicks

        Perhaps not to you, but to the rest of us who have read the standard... end to end encryption means no man in the middle attacks, no certificate authorities, etc. Every organization has access to its own key in DNS, and if someone tries to replace it, anyone who has c

        • Firstly, Microsoft has invalidated the cert (at least to my knowledge).

          Your knowledge is incorrect [google.nl]. At the request of the Dutch government, Microsoft deliberately did NOT patch its systems from that country... until several weeks later when the government's request was made public and they retracted their request.

          But Microsoft HAS pulled the cert, whereas your comment was written as if they have not yet done so. And my knowledge of this is not incorrect unless you are still implying that Microsoft has yet to invalidate those certs.

          Secondly, it is not at all clear how moving to ipv6 tells the corporations to eat a bag of dicks

          Perhaps not to you, but to the rest of us who have read the standard... end to end encryption means no man in the middle attacks, no certificate authorities, etc. Every organization has access to its own key in DNS, and if someone tries to replace it, anyone who has connected to it previously would know.

          It does not mean no man in the middle attacks. Even with IPSec you still have to trust, whether you are trusting a CA or the DNS, you are still trusting. If your ISP is your DNS provider, and they are also the best positioned to implement MITM attacks, then unless you have a shared secr

        • by billstewart (78916) on Thursday September 15, 2011 @06:14PM (#37415280) Journal

          IPv6 security options can give you end-to-end encryption similar to what IPSEC gives you, if you always turn it on.

          End to end encryption means that nobody can eavesdrop on connections that you've set up to the party on the far end. If that party is actually the party you think they are, and they're somebody you should trust, that's a Good Thing - if they're a Man In The Middle, you lose (though it reduces the number of ankle-biters who might be trying to eavesdrop on you, and it's kind of comforting to know that your credit card is only being stolen by the Russian Mafia and not by the other people in the coffee shop with you.)

          End to End Encryption doesn't give you a way to authenticate connections to people you don't already know. That's a job for certification authorities, or somebody doing a similar job. If you do already know the party at the other end, and have an authenticated connection of some kind (like a pre-shared key or a SecureID token or a courier with a briefcase handcuffed to his arm or a yellow sticky note or a PGP key on a business card that somebody who wasn't an impostor handed you ), end-to-end encryption systems can do things like Diffie-Hellman key exchange to bootstrap that into a full connection.

          "Every organization has access to its own key in DNS" is an assertion about the DNS system, not the network or transport protocols. It sounds like you're thinking about DNSSEC, which _should_ have been deployed decades ago (but among other problems, they were blocked by the US ITAR anti-crypto mafiosi.) If DNSSEC had been deployed properly along with the DNS system, you could be sure that if you had the correct IP address for microsoft.com, you'd also have the correct public key for setting up connections to microsoft.com's web site, and if you have the correct IP address for m1cr0s0tf.com, you'd also have the correct public key for setting up connections to m1cr0s0tf.com, which might or might not be somebody you want to talk to.

        • by Anonymous Coward

          Excellent spin. You should find an ambitious governor or lawyer to work for.

          At the request of the Dutch government, Microsoft deliberately did NOT patch its systems from that country

          Both Mozilla and Microsoft received a request from the Dutch government not to remove the Staat Der Nederlanden root, of which DigiNotar was a CSP. The rationale was based on two mitigating factors:
          - there was no evidence of fraudulent certificates issued under this root
          - the Dutch citizens were not under immediate threat

          Both Mozilla and Microsoft complied initially. Mozilla fucked up their whitelisting (only kept SdN root, removed

    • by hydrofix (1253498)
      Please mod parent down. IPv6 has nothing to do with preventing invalid SSL certs being issued.
  • by betterunixthanunix (980855) on Thursday September 15, 2011 @03:32PM (#37413732)
    It's not like we have reason to think that other CAs have not had unreported blunders. In fact, we have every reason to think that the whole CA system is broken, and is just hanging on because nobody is willing to put in the effort needed to replace it.
    • by vadim_t (324782)

      So what would you replace it with?

      • Gee... If only someone else had an idea... http://convergence.io/ [convergence.io]
        • by vadim_t (324782)

          There are lots of problems with that.

          Let's see:

          It depends on the availability of a third party. SSL works fine with just the server you connect to, but for this you need to talk to the same set of servers for any certificate check. That makes it easy to block. Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.

          It doesn't do many of the duties of a CA. It will happily mark as valid a certificate for gma1l.com, with the metadata copied from the gma

          • by icebraining (1313345) on Thursday September 15, 2011 @05:51PM (#37415122) Homepage

            The main benefit from this system is "trust agility". If someone hacks and obtains a root cert from Verisign, what are you (or the browser vendor) going to do? Keep the cert on the browser and risk being MITMed, or removing it and break half of encrypted websites? Diginotar was just a small CA, but what if a big one is hacked?

            Convergence/Perspectives lets you have more than one notary verifying each cert, which means you won't break anything if you need to remove trust on one of them. By itself this makes it much better than the CA system, in my opinion.

            • by vadim_t (324782)

              The main benefit from this system is "trust agility". If someone hacks and obtains a root cert from Verisign, what are you (or the browser vendor) going to do? Keep the cert on the browser and risk being MITMed, or removing it and break half of encrypted websites? Diginotar was just a small CA, but what if a big one is hacked?

              I suggested an alternative in an earlier article: Change to a system of having multiple CA signatures on a cert, so that a CA can revoke without invalidating a certificate. Eg, min 3 s

              • Yes, but the notaries are much less safe. A CA at least verifies that you control the domain/email address the cert is for, notaries don't even do that, let alone checking that the metadata is correct.

                Maybe the existing ones don't, but you could perfectly have ones that do, and you could trust just those. Or have them with different trust levels.

                Also, being able to untrust a notary is nice, but how do you know when you need to? It's a run your own if you want deal. I can imagine what will happen: enthusiastic people will set up their notary, forget about it 3 months later, and soon enough there will be lots of unmaintained ones. Your list of notaries will eventually include those running on a forgotten 486 in a closet, insecure multiuser systems, unreliable connections, and so on. Some of that can be policed intentionally, but security can't.

                Anyone can run a CA too, doesn't mean most people will trust their signature. Why would you (or your browser's vendor) add some random guy's notary to the trust list?

              • by ppanon (16583)
                Nah. Most likely is that the notaries will outsource all their IT to one or two ASPs (let's call it NotaryIT.com) and THAT gets hacked.
          • by raynet (51803)

            One thing I like about Convergence is that I can ask it to validate the cert with n+1 notaries which I hope would make it more likely that a "faked" cert and MITM would create an alert at my end. This way, as long as I am using notaries in different countries, I should be able to detect if my country has forced some CA to create wildcard cert for them to listen in to my SSL traffic.

            • by vadim_t (324782)

              I don't mind the idea of it in general, I think it can be an useful tool for somebody who knows what's going on, and what the results those systems produce mean.

              But I don't think they Covergence or Perspectives should replace the CA system. They can augment it, but they lack too many of the functions of a CA to be a good replacement.

          • It depends on the availability of a third party. SSL works fine with just the server you connect to, but for this you need to talk to the same set of servers for any certificate check. That makes it easy to block. Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.

            • CA SSL requires "third party" net access for certificate revocation checks (OCSP).
            • That CA SSL cert revocation using third parties is (as it's handled in most situations) susceptible to replay attack.
            • Blocking a potential victim's access to n out of m notaries (where n equals something of the user's choice and m equals a potentially huge number of systems) is an unlikely attack.
            • The user may decide to change their current list of notaries to circumvent a block. ("trust agility")
            • Convergence notaries appear t
            • by vadim_t (324782)

              CA SSL requires "third party" net access for certificate revocation checks (OCSP).

              That's a lot harder to abuse, though. Revocations are rare. A site that keeps using a revoked cert for very long is even rarer.

              That CA SSL cert revocation using third parties is (as it's handled in most situations) susceptible to replay attack.

              But to exploit that, you need to find a site that has something valuable, that's still using a compromised cert, to have the private key to that cert, and to replay OCSP. That's pretty t

              • What exactly is the threat model you're positing?

                Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.

                You're on such a compromised net and you visit an HTTPS site...

                • If you have the cert cached, you won't need a notary check. Authenticated communication proceeds.
                • You're seeing the cert for the first time, but Convergence can't talk to notaries. So the cert shows up as not validated. You can cope with that. Don't trust the site. Switch to the next available wireless network and try again. Maybe you'll have to leave the cafe and walk down the street. Or e
                • by vadim_t (324782)

                  And, anyway, this scenario assumes you can block the notaries. Anyone can run a notary. Not everyone has to publicize their notary.

                  Imagine I travel to an untrustworthy country. Let's say I go to China, and try to check my mail from there. Now, the government wants to know for whatever reason what I'm up to.

                  With the CA system, if they block OCSP that's not very significant for reasons I outlined before. They can block gmail.com, but then I can't get to my mail and never even send the password, so they don't

                  • The worst thing they can do is to use their CA to emit a valid cert for gmail.com and spy on me that way. That is a big problem, but I can remove the chinese CA from my system. Certainly this isn't perfect at all, but workable to some extent.

                    Remove the Chinese CA? That idea is "trust agility". You're suggesting you have some ability to change who you trust with modifying browser CA lists. It's quite minimal, really:

                    Did you remove the Diginotar cert? Or did you wait for your browser or OS to get an updat

                    • by vadim_t (324782)

                      Remove the Chinese CA? That idea is "trust agility". You're suggesting you have some ability to change who you trust with modifying browser CA lists. It's quite minimal, really:

                      I didn't say it was perfect, my point here is that in a worst case situation, a CA system still can work acceptably, even if not in an user friendly manner or using the default settings.

                      Did you remove the Diginotar cert?

                      Yes, all of them

                      And what if the CA is someone like Verisign? Do you remove Verisign? And make a quarter of HTTPS co

                    • I didn't say it was perfect, my point here is that in a worst case situation, a CA system still can work acceptably, even if not in an user friendly manner or using the default settings.

                      If we're getting down to the level of manually removing CAs, there's a lot of security inconvenience that's "acceptable".

                      ... I'm advocating for multiple signatures

                      That would certainly be an improvement.

                      And did you know that Diginotar's website had been hacked as far back as 2 years ago?

                      I see the same problem existing with no

      • by billstewart (78916) on Thursday September 15, 2011 @06:49PM (#37415540) Journal

        The current system is that your browser ships with a bunch of CA's listed in it, many of which are currently in business, and some of which are trustable, and some of which are random corporate leftovers run by shadowy anonymous figures, and if you're like most people you haven't bothered listing them (or if you did, it was years ago.) So from a technical standpoint, perhaps you're in deep trouble, but it's your own fault because you didn't look. See figure 1.

        From a business/financial standpoint, it's different. Many of those CAs are run by reputable firms, whose business models are that they'll give a certificate to anybody who pays them $100 (or whatever the going rate is this year), and they'll certify that the payer's credit card was good, and maybe, just maybe, they'll only deliver the SSL certificate to an email address or web site that matches the keys they just certified, or do some similarly minimal level of validation. Some of the CAs, of course, require more documentation, charge more money, and provide methods for a user to validate one of their certificates other than using it and seeing if their browser flagged it. But not everybody uses those CAs - Microsoft.com probably does, and Microsfot.cm probably doesn't. So from a business/financial standpoint, you're in sort of the same condition you were in in the previous paragraph, except that you can rely on the financial guarantees that the CA gave you, the user of a browser that trusted their certificate, unless you didn't pay them anything, in which case you should also see figure 1.

        Back to technology, there's the problem of whether a certificate is still good. That's backed by three things, expiration dates on the certificates, ability to validate a certificate chain, and revocation lists that the CAs provide to deal with the problem of certificates that were compromised before they expired. Expiration dates on most certificates tend to either be the remaining fraction of one year (because the CA is charging for them on an annual bases) or "already expired". And that certificate chain's useful, if the CAs on it are still in business and their certificates haven't already expired, unless their certification system has been compromised without being detected, in which case see figure 1.

        And then there's the user interface issue - if you're directly using a browser, and everything's good, it'll probably turn a little lock icon green, which you won't notice. Otherwise, it'll give you a dialog box, "Security problem - See figure 1 [Click OK]", and you'll click OK, and you'll either feel fine, or you'll have this little nagging feeling that something was wrong, but you're not sure what.

        And then there's the financial layer again. If the certificate was protecting your credit card number, and you're in the US, you're liable for at most $50 if it got stolen, and otherwise it was probably just protecting your Facebook account, in which case the worst that'll happen is somebody posting rude notes to your friends, or overwatering the shrubbery in your farm. So fundamentally, you don't care that the CA system is broken.

        One of the advantages of having been one of the early cypherpunks is that I got to watch a lot of this stuff develop, see many of the things that were done right or wrong, and know a lot of people who are either much smarter than I am (too many of them to list here) or who went out and Did The Right Thing at the Right Time (special shout-out to the Netscape folks, who went and shipped encryption for free even though the legality was dubious, which not only catalyzed the internet commerce business but broke the government's anti-crypto stronghold.) Lots of the solutions that shipped weren't perfect, and lots of the solutions that were Perfect never shipped, and lots of the solutions people spent time on didn't have problems associated with them, but it did still transform the world.

        • by thoromyr (673646)

          I good post, but I really thought in paragraph 3 you were going to mention how CRLs are fundamentally broken (essentially advisory in nature due to implementation) -- or do you disagree with that?

          • Yeah, I probably should have gone into more detail. They're ok when they work, except when they're broken, which they often are, but the better alternative is short-expiration-time certs, unless you're also trusting already-expired certificates, which most people do, in which case both common approaches are broken.

      • If we had shipped DNSSEC back before web commerce became widespread, we'd be in a lot better shape. You'd be able to know that the public key you had for microsoft.com was owned by the people who'd registered the name microsoft.com with the .com domain registry, and that the public key you had for www.microsoft.com was certified by the people who owned the name microsoft.com. It's not perfect - you'd have just as much certainty that the public key you had for mocrosoft.cm was owned by the people who'd re

      • TSA Agents!

    • by 0123456 (636235)

      It's not like we have reason to think that other CAs have not had unreported blunders.

      If they had, then someone should have copies of the fake certificates and could demonstrate that the CA was broken; any widespread use would have handed the cerfiticate to so many people that it should easily be provable.

      Otherwise that's about as logical an argument as saying there's no reason to think that I have not slept with Natalie Portman.

      • by Amouth (879122)

        problem is - for the people who break the CA's there is ALOT of money to be made. Very few people who that that chance would pass up the money to show the world that xCorp is corrupt.

        • by 0123456 (636235)

          problem is - for the people who break the CA's there is ALOT of money to be made. Very few people who that that chance would pass up the money to show the world that xCorp is corrupt.

          They're not the ones who would be showing it. If you hack into xCorp and generate a fake certificate it's useless to you unless you then hand that certificate to your victims. Those victims can then show that certificate as proof that xCorp is handing out fake certificates.

          Since no-one has shown such certificates for CAs who aren't yet known to be compromised, we can be fairly sure the others haven't been.

          Of course that may be luck rather than good security practices.

          • And how does the PHB know the certificate is fake to present it?
          • by Amouth (879122)

            if you have successfully created a fake cert from a CA - the only people who can verify that it is rouge are:

            A) the CA via audit on what they have issued (which might not show it as fake as it might be in their logs)
            B) the domain it says it's for, who ever owns it should be able to audit against their requested certs (for some places this might take awhile)
            C) the person who faked it.

            Notice NONE of the people are the end users, a actual faked cert from a CA is indistinguishable from an authentic cert from th

            • by 0123456 (636235)

              B) the domain it says it's for, who ever owns it should be able to audit against their requested certs (for some places this might take awhile)

              Exactly. If I produce a certificate for www.google.com signed by BadCA, then you can easily verify that it's not the certificate that www.google.com is sending to you over SSL, and then Google can verify that it's a certificate they've never used. And if it's a CA that Google don't use then a simple 'there's something odd going on here' check is trivial ('why is www.google.com sending me a certificate from a CA in Nowhereistan?').

              • by Amouth (879122)

                i'm sorry but do you not understand the basics of a Man In The Middle attack? and the value of a fake cert in that scenario?

                in any decent MITM attack - if i'm trying to spoof google for you - then any request from you for google will go through me and i will respond with the right answer, currently under this scenario the 3rd party trusted CA on your local machine is the only way an end user has to verify that what i say is true or false.. compromising the CA in this case allows me to make a cert that you

                • by dgatwood (11270)

                  Mandatory DNSSEC with public keys stored in the DNS record would achieve the exact same level of security without adding all sorts of unnecessary P2P traffic.

                  The only thing that the CAs ostensibly offered was some indication that the site was owned by an actual brick-and-mortar identity at some physical address, and when they switched to domain validation, even that advantage went away. Thus, they're basically vestigial. I similarly see no reason why a scheme like the one linked above would be any better

                  • by raynet (51803)

                    Doesn't DNSSEC still require a point of trust, the root dns providers in this case? How is that any better than we now have with SSL CA's?

                    • by Amouth (879122)

                      it isn't - DNSSEC in it's current incarnation has the exact same single point of failure as the current CA system.

                      Also DNSSEC is useless to a local MITM as long as clients support normal DNS as you can arp poison clients to believe you are their DNS server and respond with no DNSSEC records for the host and use your faked CA cert.

                      the point of the p2p traffic is that for a MITM to work they would have to intercept all points of trust, which while not impossible is far more difficult than exploiting a single

                    • by dgatwood (11270)

                      it isn't - DNSSEC in it's current incarnation has the exact same single point of failure as the current CA system.

                      Care to enlighten us? I don't believe that is even remotely true.

                      Assuming that in the future, all browsers treat a DNSSEC-secured address result and key in the same way as it currently treats a CA cert (such that a URL specified as https requires DNSSEC to prevent stripping of the security during the lookup process), then the DNSSEC model can only be compromised by compromising the domain itsel

                    • by Amouth (879122)

                      so your saying that just because you are reducing the number of CA's (global trusted CA's now to the domain registrars) that while it makes the # of targets less does not remove the single point of failure?

                      i'd like to point out to you your own "Microsoft" example.. VeriSign who is Both a CA and a registrar has already in the past, before we had nearly as many registrars and ca's, given a code signing cert to unknown people for "Microsoft Corporation".

                      http://technet.microsoft.com/en-us/security/bulletin/ms [microsoft.com]

                    • by Amouth (879122)

                      sorry you didn't point out "Microsoft" that was another poster above you sorry - but my point still stands.

                    • by dgatwood (11270)

                      so your saying that just because you are reducing the number of CA's (global trusted CA's now to the domain registrars) that while it makes the # of targets less does not remove the single point of failure?

                      I'm saying that it dramatically changes the equation. With DNSSEC, I (as the owner of a domain) only need to worry about whether my choice of registrar is secure. With the current CA scheme, I have to worry about whether every CA is secure.

                      More to the point, someone compromising a registrar can compromi

                    • by Amouth (879122)

                      i will agree with you - but for now DNSSEC is only useful against MITM once users stop supporting traditional DNS.

                    • by dgatwood (11270)

                      Not really. The OS doesn't hide whether a response was encrypted or not from applications. The way Chrome supports DNSSEC is that a DNSSEC response is valid for https, but an unencrypted DNS response is invalid unless the site is signed by a CA cert. I'm assuming that all browsers supporting DNSSEC will do the same.

                      So it's more correct to say that DNSSEC is only useful against MITM once browsers stop accepting certs from traditional CAs. :-)

            • this is true.. really a faked cert from a CA.. isn't fake.. it's real. it's like getting your "fake" ID from the DMV..

              • If you manage to hack the CA that issues the cert that Google uses and issue your own cert for www.google.com, then yes.

                Otherwise, it's like getting your "fake" ID from whatever the DMV is called in the Netherlands.
        • by robably (1044462)
          ALOT ISNOT AWORD
      • I am soooo jealous.

        I assume you are truthful in all your statements.

      • by sjames (1099)

        Unless nobody happens to have noticed because the the browser display for a fake (but "valid") cert and the genuine article are identical unless you right click-page info-security just to be sure, exactly like practically nobody ever does.

  • by vadim_t (324782) on Thursday September 15, 2011 @03:33PM (#37413752) Homepage

    Hopefully this will get the others CAs worried and motivate them to get better security.

    • by h4rr4r (612664)

      Why?
      They had a good run with no security at all and could pocket lots of money because of that. Clearly the lesson here is to not do any security, fold up shop if you lose accreditation and start up another CA.

      • Your argument only works if several conditions are met:

        A) They made more money than the fallout is going to cost them. It isn't cheap to close down a major business, there are lots of bills to be paid and lots of backseat accountants from both the creditors and the government making sure you don't fudge the math in your favor.

        B) The people who profited DigiNotar have enough capital or credit left over to start another major corporation

        C) Most doubtful of all, that they can convince people to trust them aga

        • by h4rr4r (612664)

          A) the CxOs will get their golden parachutes first, and that will be legal since employees are paid before anyone else.

          B) See A

          C) They will then buy up a small CA to get its trusted status. For profit colleges do this all the time. They buy up small struggling universities/colleges just to get their accreditation.

    • For values of "security" that include "PR", I have no doubt that it will...
    • by amorsen (7485)

      In a free market, if you can sell certificates for $5 with lousy security and $10 with decent security, and you have a 10% risk of losing everything with lousy security and 0% with decent security, the companies with decent security go bankrupt rapidly. After all, why pay $10 when you get the same for $5? A breach of ANY registrar is as bad as a breach of YOUR registrar.

  • The Price Of Trust (Score:5, Insightful)

    by Wiz-Hum-Mal-Cha (2443796) on Thursday September 15, 2011 @03:34PM (#37413774) Journal
    If getting compromised and issuing bad certificates *didn't* cost you your position of trust, then what credibility would the certification process have anyway?
  • by SigILL (6475) on Thursday September 15, 2011 @03:34PM (#37413776) Homepage

    If you won't properly separate your security-critical systems from your Internet-facing systems, or cannot even keep them from being rooted multiple times, you have no business being a CA.

    Honestly, it's understandable DigiNotar didn't want this information out: bankrupcy is inevitable now, and that's bad for shareholder value.

  • Those responsible at Diginotar are unlikely to feel anything more than (possible) economic consequences. Based on the location of the MiTM attacks, their incompetence wasn't responsible for some penny-ante credit card scamming, it was employed to advance surveillance by a somewhat ideologically touchy state. It would be entirely within the realm of possibility that somebody is doing hard time right now because they fucked up...
    • by idontgno (624372)

      Or, to look at it from a business perspective, no meaningful liability until someone can press some kind of human-rights-related lawsuit. Whereas if money had been lost, LOOK OUT.

      Sounds like Diginotar came out ahead in the client liability front.

  • by Dynamoo (527749) on Thursday September 15, 2011 @03:44PM (#37413924) Homepage
    What.. you reckon? They were tasked to do ONE THING and ended up in an epic case of fail and pwnage.
  • This is a popular Dutch comic: http://foksuk.nl/nl?cm=79&ctime=1315260000 [foksuk.nl]

    The guy on the left says something like "Don't panic, people. In about three months..." and the other guy continues: "...we'll have a different name and a different corporate identity!"

  • include Pidgy and Dragonite. both are formidable but the latter is a fully realized dragon type so its pretty powerful.
  • Having your product proved defective spells the end for most companies, GM almost went under and they are 1000x the size. PR and image > everything.

    Shame certs are set up in a manner where it is very difficult to fix... anything wrong with them. I believe in the whole handshake principle, but why are there root certs on my computer by default? I feel I should have to sign a EULA for those outside of the windows EULA.

    Sure it's inconvenient, but I really really really don't need MS or DigiNotar

  • So if this happened to one CA who got compromised what makes you think others will now disclose they were hacked?

    If it happens again to someone else they sure as hell wont announce it as any CEO will want to keep his job more than protect the web. If anything this could make the web less safe

    • They haven't been revoked by these major software developers (essentially destroyed as a CA) because they were hacked. They were kiled because they didn't tell anyone about it when they found the invalid certificate and revoked it themselves. It's the failure to come clean and say 'we were hacked, here's what was compromised, and here's how we fixed it.' They lost thier entire business instead of getting some bad PR because they tried to cover it up and assumptions are that next time they are hacked, we mi
  • Already dead (Score:5, Interesting)

    by plsuh (129598) <plsuh&goodeast,com> on Thursday September 15, 2011 @05:45PM (#37415076) Homepage

    This is just going through the motions. DigiNotar has been dead since August 30, when Google, Mozilla, and Microsoft all revoked trust in their certificates. Anyone with at least two brain cells (which seems to exclude a large number of managers, unfortunately) could see the writing on the wall. No one would ever buy a new DigiNotar certificate, since it would always pop up a scary warning to the user in a web browser. Why bother with buying a certificate from DigiNotar and dealing with the resulting end-user support issues, when you can buy from someone else and not have to deal with the problem?

    More interesting to me is what will happen to DigiNotar's corporate parent, Vasco Data Security? The purchase of DigiNotar is relatively recent (January 10, 2011), so it's not clear how much influence Vasco's management had over DigiNotar's operations. At the very least, Vasco is going to need to pay for an audit of its own systems to reassure its direct customers.

    --Paul

  • .... they're not a bank. We might have saved them.

  • On a related note, take a look at the certificate on www.ice.gov [ice.gov].

    The certificate hierarchy is

    • GTE CyberTrust Global Root
    • Akamai Subordinate CA 3
    • www.ice.gov

    Now that's interesting, and worrisome. Akamai possesses a wildcard subordinate CA cert that permits them to impersonate any site, even U.S. Government sites. Even the chief security officer of Akamai is worried about this. [csoandy.com]

    • by Tomato42 (2416694)
      All CA certificates can sign certificates for any and all domains. There's nothing that can stop them in X.509 from this.
      • by Animats (122034)

        The problem is that Akamai, which is not a CA, has a cert which gives it the powers of a CA.

  • Why can't we have quangos do the signing? Governments can sign for companies, performing EV using their large, centralised databases of companies (e.g. Companies House in the UK).

    Individuals may be signed off by the domain registrar subject to receiving basic identity documentation as individuals don't really need full EV'ing for their personal sites.

    Anonymous individuals can be signed by a 3rd party and warnings can be given in-browser as to how the identity has not been verified.

    Problem solved.

A computer lets you make more mistakes faster than any other invention, with the possible exceptions of handguns and Tequilla. -- Mitch Ratcliffe

Working...