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

 



Forgot your password?
typodupeerror
×
The Internet Security IT Technology

Diginotar Responds To Rogue Certificate Problem 177

An anonymous reader writes "Vasco, the owner of the DigiNotar CA implicated in the MITM attacks on Iranian Google users has responded to their fraudulently issued certificate problems. The press release reads: 'On July 19th 2011, DigiNotar detected an intrusion into its Certificate Authority (CA) infrastructure, which resulted in the fraudulent issuance of public key certificate requests for a number of domains, including Google.com. Once it detected the intrusion, DigiNotar has acted in accordance with all relevant rules and procedures. At that time, an external security audit concluded that all fraudulently issued certificates were revoked. Recently, it was discovered that at least one fraudulent certificate had not been revoked at the time. After being notified by Dutch government organization Govcert, DigiNotar took immediate action and revoked the fraudulent certificate'. It is not clear whether the latter certificate is the one used in Iran, or whether other certificates remain at large. I guess removing the root certificate from browsers is the correct response."
This discussion has been archived. No new comments can be posted.

Diginotar Responds To Rogue Certificate Problem

Comments Filter:
  • Looks like the Iranians learned a neat trick from that attack.

    • or you can be sure that iranian authorities don't interfere.

      were all victims from iran?

    • by Z00L00K ( 682162 )

      DigiNotar CA is now removed from my list of trusted root CA:s.

      I propose that all web browsers and other application should do the same since it's not certain how many compromised ones there are out there.

      Or that the private key for the root CA was kept safe.

      • Should also check the bank accounts of DigiNotar employees to see if any got an unexplained bonus.

      • How does one remove that particular CA from one's CA bundle?

        • How does one remove that particular CA from one's CA bundle?

          It depends on the browser. For Firefox you open the options, select "Advanced", click on the "Encryption" tag, and press the "View Certificates". Select "DigiNotar root CA" from the list (just start typing the name and the cursor should jump to it) and press "Delete or Distrust". Lots of steps, but all-in-all quite a simple process.

          • I haven't refreshed this page yet so I don't know if someone has already mentioned this, but it might be a better idea to click on "Edit Trust" instead of "Delete or Distrust" so that you can more-easily alter your policy for that CA later if you change your mind.
            • Thanks! I just deleted it. One can always add exceptions for specific sites if I need to. Personally, I think they should be removed entirely from the CA bundle. Trusted CAs need to be held to a very high standard IMHO.

  • by iCEBaLM ( 34905 ) on Tuesday August 30, 2011 @10:43AM (#37254224)

    ... how many forged certs are now in the wild? Nuke the CA, they are incompetent.

    • I just removed the trust setting from this CA in my browser. So can anyone else. Anyone know a site for which they've issued a cert to test and see if this actually makes any difference?

      • Re: (Score:2, Informative)

        by Anonymous Coward

        check their site, they sign their own certificate ::

        https://www.diginotar.com/Products/ExtendedValidationSSL/tabid/622/Default.aspx

      • by xaxa ( 988988 )

        I just removed the trust setting from this CA in my browser. So can anyone else. Anyone know a site for which they've issued a cert to test and see if this actually makes any difference?

        Their own [diginotar.nl] (it just redirects to the non-SSL site, but that should be sufficient for you).

      • by ComaVN ( 325750 )

        A lot of (most?) dutch intra-government traffic uses their certificates.

        See https://loket.amsterdam.nl/ [amsterdam.nl] for instance

    • by GSloop ( 165220 )

      True enough....

      But the whole framework behind certificates and CA's is the problem. This is just a symptom of the problem.

      Moxiespike: "Who are you going to trust, and for how long?"
      If the answer to how-long, is forever - then you probably have a problem.

      The problem is there's no real way to handle problem CA's - and you don't get much choice, and the system is too moribund and static to respond to problems like this.

      So, yes we can fix this *specific* problem by getting every browser to re-work the trusted C

      • Of course, Convergence relies on the user having any clue whatsoever of whether (s)he should trust a particular Notary or not.

        We're talking about users who use the same password repeatedly, who use mostly 6 and 7 char passwords, who use 'password' and '123456', etc.

        • by GSloop ( 165220 )

          But it doesn't have to stay that way.

          A vendor could easily offer a service to customers that would be the expert in choosing the notary's who are trustworthy, perhaps offering their own notary service as well. Now the vendor selling this service has an incentive to actually protect the user - since if they don't, they lose trust and then lose the customer and their dollars.

          And given a little time I'd guess there would be several stable notaries out there and would be well trusted.
          There would be services tha

      • The web has a problem. How do we tell if a URL is trustworthy?

        I know, lets create certificates backed by certificate authorities!

        Now the web has two problems.

    • by Z00L00K ( 682162 )

      Especially since even if you revoke a certificate it still requires that someone checks the revocation list - and if you are behind a wall or suffer from a man in the middle, can you be sure that the revocation list is the correct one?

      Once a CA is failed - it's completely and utterly failed as a trusted entity. And if someone got hold of the private CA key - then it's a clusterfsck.

      • Any competent CA uses an HSM. I can even imagine using an HSM is a requirement for inclusion into the default CA bundle in webbrowsers.

        An HSM is a Hardware Signing Module. It's a piece of hardware (supported by OpenSSL, by the way) which holds the secret keys. Secret keys cannot possibly be copied out of the HSM, except for backup purposes. But the backups are encrypted within the HSM itself, so the backed up keys can't be used for signing.

        Diginotar, as most CA's I know of, uses multiple secret keys. One ke

        • by Z00L00K ( 682162 )

          But it still doesn't resolve the fact that the revocation has to be propagated, and it's not often working well with certificate revocation lists - often due to user error and trouble setting up the CRL handling in the web browser or other application.

    • I'm wondering who the initial external auditor who missed the cert not being revoked in the first check. They need to be named and shamed as well.
    • OK whether they are incompetent or not is another matter, some questions arose from this whole issue.

      From other comments it seems there is no system in place to automatically revoke certificates. I really don't understand this, such an oversight. Breaches can not be prevented, no matter how hard you try (and of course the CAs should do their utmost best), so there is a need for revoking any certificates automatically and instantly. For example by having the browsers check a CA with the issuer or at DNS lev

  • In Firefox 6 (Score:5, Informative)

    by janeuner ( 815461 ) on Tuesday August 30, 2011 @10:49AM (#37254292)

    1) Options -> Advanced -> Encryption -> View Certificates
    2) In the Certificate Manager window, click the Authorities tab.
    3) Scroll down to DigiNotar.
    4) Delete or Distrust the "DigiNotar Root CA" certificate.

    • And do the same for Comodo while you're at it.

      • by Necroman ( 61604 )

        And do the same for Comodo while you're at it.

        Care to explain why?

      • The sucky part of that is that's who I get my email pgp keys from. But really there needs to be a tiered CA system, where a CA is providing certs to anyone that asks, to people that have to prove themselves, and to government and other trusted sources. The way things are now, pulling the plug on an entire CA is the nuclear option.

        • I agree that government would be a logical choice to provide this service. It would be sensible to build a geographic web of trust, where citizens authenticate themselves with the municipality, the municipalities trust the governors, and the governors trust one another.

          I would also enjoy the conspiracies that this model would create.

          • How about we all just provide the public key via a nameserver record and cut the CA out of the mix altogether. Use secure DNS and you are good to go.
        • by wrook ( 134116 )

          The sucky part of that is that's who I get my email pgp keys from. But really there needs to be a tiered CA system, where a CA is providing certs to anyone that asks, to people that have to prove themselves, and to government and other trusted sources. The way things are now, pulling the plug on an entire CA is the nuclear option.

          Why do you need to get your email pgp keys from *anybody* except yourself? There are very few transactions where someone needs to know your actual identity. Most of the time, they need to know that you are the same person they talked to last time. Meet someone online (or even IRL) and exchange keys. Now when you receive email from that person you know that it is the person you talked to previously (as long as the key exchange is not compromised). Who cares what your real name is, or where you live, etc

          • by v1 ( 525388 )

            Why do you need to get your email pgp keys from *anybody* except yourself? There are very few transactions where someone needs to know your actual identity.

            Actually, I had to get a key pair from verisign for a previous employer who required my mileage forms to be submitted via signed email. But then verisign dropped their free basic email keys so I had to move to comodo. (are there any better/other free options?)

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Unfortunately, this doesn't entirely fix the issue. Diginotar has certificates that have been cross-signed, meaning they can be used as intermediates in a chain rooted by another CA.

      • by phayes ( 202222 )

        A larger problem is that all the certs that are delivered in Firefox are hard coded (will come back as soon as you quit + relaunch firefox) and have been multiplying.

        This more than anything else is pushing me to abandon firefox for Chrome which has many fewer cert authorities that I see no reason to trust.

        Comodo has already proven themselves to be insufficiently competent. Now why the hell should I trust Turktrust?? Hong Kong Post?!? Chungwa Telecom?!? CNNIC?!?

  • So not only did they hide a break-in from the internet at large, including companies (e.g. Google) which were by extension the target, but they also aren't able to tell how many or what kinds of fake certificates got generated by the break-in? If you ask me their entire CA needs to be revoked, and a new one started. They can then re-issue all legitimate certificates under the new CA. That is the only safe way to do it.
    • Or better still: revoke their entire CA, and *don't* start a new one.

    • by mlts ( 1038732 ) *

      They need to not just dump every single private key, but do it the right way, and use hardware security modules that limit access, and what access is granted is thoroughly logged.

      RedHat had a break-in a few years back with a blackhat getting access. The attack was mitigated of in a matter of hours, and the damage was very limited (with "blacklist" keys sent out for the rogue packages that were signed.) A CA has to have their core keys in a HSM, or they should not be in business because their whole commerc

    • by jesseck ( 942036 )

      So not only did they hide a break-in from the internet at large, including companies (e.g. Google) which were by extension the target, but they also aren't able to tell how many or what kinds of fake certificates got generated by the break-in?

      The way I hear the quote from the summary

      On July 19th 2011, DigiNotar detected an intrusion into its Certificate Authority (CA) infrastructure

      is "We found out this week that fraudulent certificates were issued on July 19th..."

  • Can someone explain why a .nl organization has the power to produce .com certs? I mean, isn't this an obvious flaw in the domain/ssl/registrar/CA/whatever hodgepodge we take for granted everyday? Is it even possible to limit these guys or is it "Hi, you're a CA now, you can do anything!"

    I remember the same thing happening with a different foreign CA not too long ago and a lot of hand wringing over state owned telecoms in China/Iran/Syria and other autocratic nations. The domain name system works like this.

    • The chain-of-trust model is not hierarchical. Many CA certificates do not include a domain name at all. It is all about the certificate subject and the key usage flags.

    • by BZ ( 40346 )

      > Can someone explain why a .nl organization has the
      > power to produce .com certs?

      To avoid having a monopoly in the CA space?

      But yes, having some limits on what CAs are trusted to issue certs of which sites what is a good idea, and I fully expect browsers will move in that direction. I'm certainly pushing for it.

  • by Rich0 ( 548339 ) on Tuesday August 30, 2011 @10:57AM (#37254444) Homepage

    We REALLY need a better way to handle root CAs.

    First, there should be one list of CAs for the system - not one for every application on the system. Why should Firefox, Thunderbird, Chrome, IE, and who knows what else all have an embedded list?

    Second, that list should be easy to update without having to download new copies of all your software.

    Ideally, that list should have its own CRL of sorts - so that automated revokes of root CA certificates can be done with a simple process. That should be a fail-safe mechanism - if the CRL can't be authenticated in some period of time, then a warning is displayed or all certificates relying on that CRL become invalid.

    • Right and while we're at it, they should be subject to random security audits. Given that the signing key doesn't need to be present on a network to work, I'm not really sure I understand how a breach like this couldn't have been prevented.

    • Debian has /usr/sbin/update-ca-certificates that reads certificate configuration from /etc/ca-certificates.conf and generates the certificate store for any applications that use the mechanism, which includes openssl, Firefox, and Java as installed from the Debian repositories.

      I would think it would be easy to write a program that does the CRL checking as you described and remove the entries from /etc/ca-certificates.conf.

    • I disagree. I trust public CAs for web browsing. I trust my company CAs for company email.

      The reverse of this is not true.

      TBH, we should have certificate stores for each application. In a perfect world, I should install my bank's certificate as a trusted certificate, and distrust Thawte, Verisign, etc when visiting mybank.com. But alas, that is hard.

  • Comment removed based on user account deletion
    • Iran is excluded because they're not to be trusted. The real question is why we trust the Israelis and some of the other folks we trust.

  • by fuzzyfuzzyfungus ( 1223518 ) on Tuesday August 30, 2011 @11:03AM (#37254546) Journal
    We at Vasco love the passive voice more than our own mothers. Also, all appearances to the contrary, we aren't colossal fuckups because, when we colossally fucked up, we "acted in accordance with all relevant rules and procedures"(this apparently didn't include mentioning that there had been an issue). Thankfully, we hire external auditors who operate well on our level of understanding, so they didn't reveal the embarrassing scope of our failure. After somebody else entirely did our job for us, we finally got around to cleaning up what of our mess was still within the realm of fixable(sorry, Iranian Gmail users, hope you weren't doing anything seditious..)

    So, is there any reason that this company shouldn't just be sold for scrap now? Their security clearly isn't good enough, their secretive attitude isn't exactly in line with being a 'trusted' certificate authority, and they can't even hire the right outside assistance to help them clean up their own messes. Hell, at this point, my very own FuzzyFuzzyFungus' SporeCert(tm) trust solutions would appear to be a better bet...
    • by pe1chl ( 90186 )

      I also find it quite disgusting how they mainly focus on the damages potentially being done to their own company and the profits it might or might not generate, instead of considering the damages done to others, in this case even to individuals that may pay for this incident with their lives.

  • by Animats ( 122034 ) on Tuesday August 30, 2011 @11:14AM (#37254678) Homepage

    Currently, root certificates are wildcards, usable for any TLD. They need to be restricted to a single TLD, or a short list.

    Single-nation CAs and government-operated CAs should be restricted to their TLD. For the generic TLDs, ("com", ".net", etc,) the CA/Browser Forum should require the CAs to post a large bond [cabforum.org], from which a penalty is forfeited if any improperly issued cert is found. That should get the problem under control.

  • Could one not send CSRs to more than one CA and the browser indicates how many CAs responded ok?

  • Too late (Score:5, Informative)

    by slasho81 ( 455509 ) on Tuesday August 30, 2011 @11:40AM (#37254974)
    Too little, too late. I already removed DigiNotar from my trusted CA list. You should too. In Firefox: Options > Advanced > Encryption > View Certificates > Authorities tab > Find DigiNotar > Edit Trust.
  • this is a good day for liberties, because this kind of sh...stuff exposes any type of 'authority' for what they really are, be it a gov't or any other so called authority (especially the kind that people just trust without questioning).

    Since when are people just blindly trusting one another? Government like structures? Isn't this a sure way to get completely screwed by whoever you are trusting?

    The entire model is wrong, of-course. There is a need for a bunch of competing systems, open, distributed, easy to

    • by phayes ( 202222 )

      Mod parent up please!

      Wow, just Wow, Diginotar appears to have been hacked a loong time ago & is only now discovering it!

  • In MacOSX (Score:5, Informative)

    by Jeremy Erwin ( 2054 ) on Tuesday August 30, 2011 @01:03PM (#37256016) Journal

    open /Applications/Utilities/Keychain Access.app
    Click on System Roots
    Scroll down to DigiNotar Root CA
    Click the "i" icon, or select "Get Info CMD-I"
    Expand the "Trust" node
    For the "When using this certificate"
    Select the "Never Trust" option

    If successful, the info window will now say "This certificate is marked as not trusted for all users"--- and you can browse this site [diginotar.nl] to ensure that the trust is broken.

  • Correct me if I'm wrong, but assuming we can achieve secure DNS, it becomes much more simple to associate a site's certificate with only the associated domain registrar, instead of the HTTPS equivalent of allowing any registrar to vouch for a certificate.

    As other posts have noted, part of the problem is that ANY of the certificate authorities can vouch for a certificate. By keeping the trust path narrow (root->singular registrar->domain) instead of wide (root->all registrars->domain), breaches

  • With every domain name you own you should be able to get an SSL cert with your registration/renewal. I want to register this domain and here is my CSR as part of the registration process.

    CAs were supposed to verify you independantly of domain ownership so that identity problems such as bad actors getting certs for gooogle.com..could not occur.

    Today the process has been soo watered down humans are too many cases not even in the loop. All distinction between identity and domains for all practical purposes

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]

Working...