|
|
Subscribe / Log in / New account

Fraudulent *.google.com certificate issued

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 2:40 UTC (Tue) by cesarb (subscriber, #6266)
In reply to: Fraudulent *.google.com certificate issued by kjm
Parent article: Fraudulent *.google.com certificate issued

The public bug report seems to be https://bugzilla.mozilla.org/show_bug.cgi?id=682956 (but the true bug report seems to be restricted, and not even its number seems to be publicly known).

If I understand correctly the comments there (in particular https://bugzilla.mozilla.org/show_bug.cgi?id=682956#c10), it is more than just removing: it is blacklisting _by name_.

We probably will know how bad it was only after the true bug report is opened up.


to post comments

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 3:27 UTC (Tue) by josh (subscriber, #17465) [Link] (9 responses)

Blacklisting by name alone seems like a bad idea; the root CA also needs blacklisting by fingerprint. After all, this incident will probably force them to retire their current brand entirely.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 4:04 UTC (Tue) by dlang (guest, #313) [Link] (8 responses)

blocking by name is broader than blocking by fingerprint.

blocking by fingerprint blocks one particular CA cert, blocking by name blocks every CA cert with that name, effectively passing a death sentence on that CA (at least under that name, and if the same people submit a new CA to be accepted by the browsers, it's unlikely to be accepted)

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 22:36 UTC (Tue) by martinfick (subscriber, #4455) [Link] (7 responses)

> and if the same people submit a new CA to be accepted by the browsers, it's unlikely to be accepted)

How would that work?

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 22:43 UTC (Tue) by dlang (guest, #313) [Link] (6 responses)

well, if a CA has done something bad enough to be removed (and as far as I am aware, this case is a first), then the same people who had to do the removal and deal with the fallout are the same people who would have to approve putting a new CA into their software, I figure they are unlikely to risk getting into the same mess a second time with the same people.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 22:51 UTC (Tue) by martinfick (subscriber, #4455) [Link] (5 responses)

What is mozilla suppose to track who works for whom now? If not, what do you mean the same people?

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 15:43 UTC (Wed) by raven667 (subscriber, #5198) [Link] (4 responses)

I would think they do _some_ amount of due diligence that when some CA emails them a public key as says "trust us" that they figure out if where it's coming from is legit. In fact I know that the process is somewhat expensive and can take quite a while from when I worked at an internet company which was also a CA trying to get their new key in vendors default keychains.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 15:56 UTC (Wed) by martinfick (subscriber, #4455) [Link] (3 responses)

I am not saying they don't do anything, but I am asking how one would even attempt to approach this problem. So far, you haven't given the slightest hint to how this might actually be possible. I think that it is most likely an extremely vague untractable problem.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 16:37 UTC (Wed) by raven667 (subscriber, #5198) [Link]

It's a human problem not a technical one which is why it might seem vague. Clearly a "new" CA showing up in the same area as the old one would come under extra scrutiny. They could check their WebTrust audits and registration and see who audited them and what they found. They could check who are the officers and ownership of the company, how long the company has been around, if it shares office space with the "old" company. They could look at public tax info to see if the organization has been around and has books that make sense. If the company is public they could look at the books themselves (heck for high-value sales private companies have been known to let potential customers look at the books to reassure them).

Building up the paper trail that a CA needs to be accepted by the browsers does require effort and time but you are right in that I have not worked close enough to the CA/browser relationship to know exactly what is required to register with MS, Mozilla, Apple, Opera, Oracle, Google, RIM, and other vendors.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 7:56 UTC (Thu) by Comet (subscriber, #11646) [Link] (1 responses)

This is what companies like Dunn & Bradstreet do, and the other old major merchant houses.

Things like Linkage Analysis, where they figure out which companies own which other companies, and trace down who actually owns a company.

It's human legwork to maintain their databases. Thus they get to charge money for queries against them.

So, I certainly hope that the major CAs are doing at least a paid check with one of the merchant houses before issueing EV certs, and anyone bundling together a group of CAs for others to trust should either be saying "don't trust us, this is just what we find convenient" (amateur, but sometimes appropriate) or should be doing the same due diligence.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 18:20 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I'm pretty sure they do, I know the CA I used to be involved with did D&B checks and gathered other docs before issuing new EV certs. The data gathering process usually took a couple of weeks and had to be validated by certified individuals and the actual issuance had to be performed by two managers.

In this case though attackers are believed to have compromised the infrastructure and had enough access that they could issue whatever they liked without going through the audit and security controls. The technical measures which could prevent this are difficult, cumbersome, expensive and not foolproof. At some point you have to be able to accept a CSR from a customer and expose it to the HSA and receive a result. If you can get anywhere in that path you can send your own CSRs and have whatever you want signed.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 6:46 UTC (Tue) by imphil (subscriber, #62487) [Link] (1 responses)

They are blacklisting by name and even disallowing overrides for older certs, see http://groups.google.com/group/mozilla.dev.security.polic...

"The
current patches to Mozilla products will blacklist all DigiNotar-issued
certificates based on "CN=DigiNotar " in the certificate issuer. Users
will be able to add a certificate override for DigiNotar-issued
certificates that have a notBefore date prior to July 1, 2011. Users
will not be able to add a certificate override for any DigiNotar-issued
certificates with a notBefore date after July 1, 2011, which would
include the *.google.com certificate. "

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 10:13 UTC (Tue) by cesarb (subscriber, #6266) [Link]

I read that double negative as the opposite: they are disallowing overrides for *newer* certs (notBefore is the date when a certificate starts being valid, notAfter is the date when a certificate expires).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds