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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: certificates, certification authority, hackers, iran, security
Companies: diginotar, google
Reader Comments
Subscribe: RSS
View by: Time | Thread
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Response to: Anonymous Coward on Aug 30th, 2011 @ 2:32pm
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
http://en.wikipedia.org/wiki/Daniel_J._Bernstein
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Tough problem to solve
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.
[ link to this | view in chronology ]
Re: Tough problem to solve
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.
[ link to this | view in chronology ]
Re: Re: Tough problem to solve
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Of course, there will be no DNSSEC if PROTECT IP passes...
[ link to this | view in chronology ]
Re: Of course, there will be no DNSSEC if PROTECT IP passes...
[ link to this | view in chronology ]