Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 22:43 UTC (Tue) by dlang (guest, #313)
In reply to: Fraudulent *.google.com certificate issued by martinfick
Parent article: Fraudulent *.google.com certificate issued

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.