Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 18:06 UTC (Thu) by raven667 (subscriber, #5198)
In reply to: Fraudulent *.google.com certificate issued by Comet
Parent article: Fraudulent *.google.com certificate issued

So are you saying that for spoofing foobix.com for example you would need a duplicate key for "foobix" signed by the real key for "com", or a duplicate "com" signed by the real root. If so then I think we are saying the same thing, either you have to get duplicates signed by the real keys or you have to spoof the whole thing from the root on down.

One difference between the existing CA infrastructure and DNS that I just thought about is that for DNS there is a lot of coordination to prevent duplicate registrations as dups are not allowed whereas there is zero technical protection from CAs signing anything they like.

Fraudulent *.google.com certificate issued

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

For spoofing foobix.com, you need fake keys for the root, for com. and for foobix.com. But you don't need fake keys for any domain you're not interested in, as you just sign the anchors for the legitimate keys with your key. And this signing can be done inline, at speed.

CAs can constrain themselves with nameConstraints; more commonly, a trusted CA would charge $$$ for a corporation to be able to issue their own certs without needing to go up, because the corp has scaling issues getting their own root cert onto every client device in a trusted manner, across all the vendors and contractors and the like; so example.com megacorp pays $$$ to the root CA for a basicConstraints CA:TRUE cert and the root CA preserve their income stream by making sure the newly minted CA cert has nameConstraints=permitted;DNS:*.example.com in it.

Another reason to be worried when software doesn't do any certificate chain validation, or tries to roll its own validation steps for the chain.

What's needed is constraints _outside_ the CA's control. A nameConstraints which can be applied to the CA, to keep the certs in-country and optionally warn for use outside the country, for vetting/approval (but default to block, to avoid continuing to train people to click through stuff they don't understand). What's needed is more of the steps like Google's cert-pinning, letting site operators at least get as far as the SSH security model of "latch on first use". Not ideal, but a massively reduced attack window (which can be shrunk to zero if you get the pinning into the source, rather than learnt; that then leaves "just" compromise of the browser distribution mechanism ...)

See:
http://scarybeastsecurity.blogspot.com/2011/04/fiddling-w...

Fraudulent *.google.com certificate issued

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

I see, in bulk you can just strip the legit signature and replace with your own. Thank you for the patient explanation.