Evidence Suggests DigiNotar, Who Issued Fraudulent Google Certificate, Was Hacked Years Ago

from the diginot dept

The big news in the security world, obviously, is the fact that a fraudulent Google certificate made its way out into the wild, apparently targeting internet users in Iran. The Dutch company DigiNotar has put out a statement saying that it discovered a breach back on July 19th during a security audit, and that fraudulent certificates were generated for "several dozen" websites. The only one known to have gotten out into the wild is the Google one. Either way, as everyone scrambles to clean this up, you should remove DigiNotar from your browser trust root (usually under "advanced" or somewhere in the options). Whether or not you do this, DigiNotar is probably effectively dead as an ongoing issuer of security certificates. No one will trust them again.

So how was this done? The folks at F-Secure have found some evidence suggesting the company was hacked by Iranian hackers (probably working for the government). But what's really scary, is that the evidence F-Secure found suggests that DigiNotar was hacked at least two years ago. F-Secure also takes issue with DigiNotar's explanation concerning how this one fraudulent Google certificate got out:
While Diginotar revoked the other rogue certificates, they missed the one issued to Google. Didn't Diginotar think it's a tad weird that Google would suddenly renew their SSL certificate, and decide to do it with a mid-sized Dutch CA, of all places? And when Diginotar was auditing their systems after the breach, how on earth did they miss the Iranian defacement discussed above?
Realistically, this raises a much larger issue about our reliance on these Certificate Authorities, and what happens when their security is weak, as appears to be the case with DigiNotar. As the EFF notes, it's time to move beyond this method of security:
As the problems with the certificate authority system become clear, lots of people are working on ways to detect and mitigate these attacks. Chrome's pinning feature is available not only to Google web sites but to any webmaster; if you run an HTTPS site, you can contact the Chrome developers and get your site's keys hard-coded. Other browser vendors may implement a similar feature soon. The same result could also be achieved by giving web sites themselves a way to tell browsers what certificates to anticipate—and efforts to do this are now underway, building on top of DNSSEC or HSTS. Then browsers could simply not believe conflicting information, or at least provide a meaningful way to report it or warn the user about the situation.
Of course, there will be no DNSSEC if PROTECT IP passes... Another reason to worry about that law, as it closes off one path to protect against these kinds of attacks.


Reader Comments (rss)

(Flattened / Threaded)

  1.  
    icon
    SD (profile), Aug 30th, 2011 @ 2:27pm

    Seems like most of these problems involve one trusted root changing to another completely different one in the spoofed cert. Browsers should easily be able to throw up a red flag if the old CA doesn't match the new one. A user might click through it, but a graphical web of trust model should be implemented too. If a user in Iran is shown on a world map that the change is concentrated in Iran they would know some funny business is going on.

     

    reply to this | link to this | view in thread ]

  2.  
    identicon
    Anonymous Coward, Aug 30th, 2011 @ 2:32pm

    Yes because DNSSEC is so much better... as Bernstein explains you could just DDoS the entire world.

     

    reply to this | link to this | view in thread ]

  3.  
    identicon
    Anonymous Coward, Aug 30th, 2011 @ 2:41pm

    Tough problem to solve

    "if you run an HTTPS site, you can contact the Chrome developers and get your site's keys hard-coded."

    a) I don't think this could scale very far (a couple dozen are supported so far).
    b) google in essence becomes the cert authority - who's to prevent them from getting false info.
    c) These are hard-coded into the binary. If google wants to revoke a trusted cert, they have to wait for users to update chrome.


    Tackling this issue is a valuable endeavor, and I'd love to see other ideas. Its not a simple problem.

     

    reply to this | link to this | view in thread ]

  4.  
    identicon
    eric, Aug 30th, 2011 @ 2:50pm

    I don't consider myself an expert, but I have looked into their service for the Dutch organisation I work for and thought it was a big step forward in getting communication between companies digital. No longer paper and stamps, but fast and trusted emails. That "trusted" part was the most important. Diginotar is a TTP (TRUSTED third party, oops) and the safety aspect is considered crucial by our lawyers. A small experiment with the service will now be a little bit further in the future I guess. Also shows that my line of business (post and archives) has changed from putting date stamps with red ink on paper to reading Iranian dissident blogs. Any suggestions about which websites/blogs it is smart to follow if you have my job (in Holland I follow "Breed")?

     

    reply to this | link to this | view in thread ]

  5.  
    icon
    DinDaddy (profile), Aug 30th, 2011 @ 3:01pm

    Of course, there will be no DNSSEC if PROTECT IP passes...

    The internet routes around damage.

     

    reply to this | link to this | view in thread ]

  6.  
    identicon
    Anonymous Coward, Aug 30th, 2011 @ 3:02pm

    Response to: Anonymous Coward on Aug 30th, 2011 @ 2:32pm

    A cure worse than the disease

     

    reply to this | link to this | view in thread ]

  7.  
    icon
    SD (profile), Aug 30th, 2011 @ 3:16pm

    Re: Tough problem to solve

    Except Google isn't offering to hard-code site certificates at all.

    They are offering to hard-code the new "HTTP Strict Transport Security" setting, which solves a different problem. HSTS just forces a browser to load a site via HTTPS all the time rather than HTTP. It doesn't need to be hard-coded. A site owner can set up a HSTS response header on their site themselves, and upon every subsequent reload of their site it will never attempt an unencrypted connection until the header expires. Most likely Google will end up only hard-coding a list of payment processors and banking institutions or remove hard-coding completely.

     

    reply to this | link to this | view in thread ]

  8.  
    identicon
    Anonymous Coward, Aug 30th, 2011 @ 3:25pm

    Re:

    Bernstein is the idiot responsible for worthless crap like qmail -- which neatly "solved" various SMTP problems by ignoring the standards. He is not, repeat NOT, any kind of expert on real-world network/server/service management issues.

     

    reply to this | link to this | view in thread ]

  9.  
    identicon
    Anonymous Coward, Aug 30th, 2011 @ 3:29pm

    Re: Re:

    Really? What worthless crap did YOU write? Are you an expert in cryptography? I thought so. So shut up instead of writing useless crap in blogs.

    http://en.wikipedia.org/wiki/Daniel_J._Bernstein

     

    reply to this | link to this | view in thread ]

  10.  
    identicon
    Anonymous Coward, Aug 30th, 2011 @ 3:48pm

    Re: Re: Tough problem to solve

    That makes more sense. So that whole paragraph from the EFF about "Chrome's pinning feature is available not only to Google web sites but to any webmaster" is a bit of bunk then?

     

    reply to this | link to this | view in thread ]

  11.  
    identicon
    Anonymous Coward, Aug 30th, 2011 @ 4:18pm

    Re: Re: Re:

    I'm sure that many novices are unaware that there is a huge gap between theoretical cryptography and actual real-world functional, usable, scalable cryptography.

     

    reply to this | link to this | view in thread ]

  12.  
    identicon
    Anonymous Coward, Aug 30th, 2011 @ 4:52pm

    Re: Re: Re: Re:

    Even if you dislike him extremely, it doesn't take away the false sense of security that DNSSEC creates, and the end problem of being able to flood using it. He still proves the concept.

     

    reply to this | link to this | view in thread ]

  13.  
    identicon
    Anonymous Coward, Aug 30th, 2011 @ 6:11pm

    Re: Of course, there will be no DNSSEC if PROTECT IP passes...

    What happens when America is considered 'damaged'?

     

    reply to this | link to this | view in thread ]


Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here
Get Techdirt’s Daily Email
Save me a cookie
  • Note: A CRLF will be replaced by a break tag (<br>), all other allowable HTML will remain intact
  • Allowed HTML Tags: <b> <i> <a> <em> <br> <strong> <blockquote> <hr> <tt>
Follow Techdirt
A word from our sponsors...
Essential Reading
Techdirt Reading List
Techdirt Insider Chat
A word from our sponsors...
Recent Stories
A word from our sponsors...

Close

Email This