Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 16:51 UTC (Tue) by job (guest, #670)
In reply to: Fraudulent *.google.com certificate issued by dkg
Parent article: Fraudulent *.google.com certificate issued

You can not tamper with DNSSEC replies. That's the whole point. Of course, you have to trust the root (and your system administrator, which is likely a weaker link) but that's about a billion times better than hundreds of CAs (where all of them needs to be secure).

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 16:57 UTC (Tue) by dlang (guest, #313) [Link] (17 responses)

if the government is out to get you, what makes you think you can trust the root?

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 17:16 UTC (Tue) by dkg (subscriber, #55359) [Link] (8 responses)

This is exactly my point. We need distributed/decentralized naming schemes that allow corroborative assertions so that our tools can actually reflect explicit, considered reliance on naming/identifying authorities. DNS as currently implemented (including DNSSEC) doesn't provide this decentralization, so it doesn't solve the underlying problem.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 18:44 UTC (Tue) by raven667 (subscriber, #5198) [Link] (6 responses)

IIUC one would need to run an entire shadow DNS infrastructure to pull this off, their own root which signs all of the second level domains which signs all of the third level domains, probably creating the keys as requests come in and caching them. I imagine that this is well within the capabilities of a well funded government program but it would be interesting to figure out exactly how complex the spoofing would need to be to successfully subvert DNSSEC so as to enable this kind of monitoring, how much it would cost. Then we can figure out what the risk is.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:03 UTC (Tue) by dkg (subscriber, #55359) [Link]

Or, a powerful adversary could just lean on one of the parties holding a key that sits "above" the target domain, and request that the keyholder quietly provide a properly-signed RR that delegates a sub-zone to the adversary.

Then, the adversary serves this RR in response to the victim's DNS request, and manages the sub-zone themselves. With such an RR in hand, the adversary only needs to control the victim's upstream network connection in order to be able to compromise the integrity and confidentiality of their communications.

if the delegated zone is a high-level one (e.g. .com), then something like phreebird in front of a filtering DNS cache should be fine (filtering to replace the authoritative keys for the sub-zones with its own key, that is). It would take a bit of engineering, but it's far from an insurmountable task.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:15 UTC (Tue) by butlerm (subscriber, #13312) [Link]

>one would need to run an entire shadow DNS infrastructure to pull this off

At a minimum you would need the DNS root private key (or the cooperation of the people who hold the key) to do this without compromising the client, which places it out of reach for any but the governments powerful enough to compel ICANN to give them the key or sign a full set of compromised TLDs for them.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 8:26 UTC (Thu) by Comet (subscriber, #11646) [Link] (3 responses)

No, you'd only need to fake up the first level signatures on the TLDs, and then into any TLD where you want to be able to filter traffic; the public keys for the sub-zones are published in the DNS, so for those you want to preserve you just pass through a delegation into the existing keys.

Given that DNS implementations are optimising for fast signing for NSEC3 anyway, it's not an impressive feat to transparently re-sign only those areas needed.

Fraudulent *.google.com certificate issued

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

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.

Distributed naming system

Posted Sep 1, 2011 20:09 UTC (Thu) by robbe (guest, #16131) [Link]

There's the namecoin system forked from and inspired by bitcoin:
https://github.com/vinced/namecoin

I don't know whether that's viable though. Bitcoin itself seems to have scaling problems if applied to something as large as current DNS.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:00 UTC (Tue) by butlerm (subscriber, #13312) [Link] (5 responses)

>if the government is out to get you, what makes you think you can trust the root?

Perhaps because the root is operated by an organization with no reason to tamper with it, in a country where tampering with a major domain would shortly become common knowledge and lead to major political repercussions?

Assuming the .com registry cooperated, intercepting, re-encrypting, and forwarding a large fraction of Google's HTTPS traffic would be a bit of a trick too. The only way a large government could get away with it is with Google's help, because they would probably be the first to know.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:12 UTC (Tue) by dkg (subscriber, #55359) [Link] (4 responses)

intercepting, re-encrypting, and forwarding a large fraction of Google's HTTPS traffic would be a bit of a trick too.

Unless, of course, the adversary is doing a more targeted attack against a specific network they happen to be upstream of.

In that case, they can ignore all the rest of the traffic, and focus their resources on compromising traffic coming out of a network segment they are interested in.

But my larger concern here isn't about Google being compromised. That's bad, but (as the current situation shows) Google actually has the resources and infrastructure to potentially catch when something is going wrong. What about smaller sites? Google vs. a medium-sized government is like King Kong vs. Godzilla. It's not clear who would win. But what if one of these titans turns their focus on small fry? Our current infrastructure suggests a sorry future for the hope of a free and autonomous global network.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 19:38 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

How does that work in practice? Wouldn't you need to have a key signed by the next highest upstream authority to make this work, or do clients not do any checking if the key for com. changes between requests? Wouldn't the only sure-fire way to do spoofing for foobix.com. be to have a shadow root with its own complete key infrastructure for all possible zones all the way down to the one that is being spoofed? You aren't going to be able to re-use any of the legitimate public key material because the trust relationships won't be compatible with the spoofed resources, right?

As long as clients don't accept the upstream keys in the hierarchy changing between requests, to spoof one child domain you have to spoof them all, right?

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 22:53 UTC (Tue) by jebba (guest, #4439) [Link] (2 responses)

I'm not certain of it, but it appears to me that x86_64 Firefox in Fedora 14/15 doesn't check the intermediate certs:
https://bugzilla.redhat.com/show_bug.cgi?id=732144

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 0:29 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

Did you check if Firefox had cached the intermediate certificates? It can make things appear to work, but when you try with another computer which has not visited yet any site which uses the same intermediate certificate, it will fail.

(I believe Firefox switched to also caching intermediate certificates because, since Internet Explorer caches intermediate certificates, a lot of people forgot to put the whole chain on their servers, and it "worked" on IE but failed - as it should - on Firefox.)

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 1:35 UTC (Wed) by jebba (guest, #4439) [Link]

Good suggestion. I believed I would have blown out my ~/.mozilla in the various tests, but I'll confirm that.

Trust the root -- trusssst it

Posted Sep 1, 2011 20:41 UTC (Thu) by robbe (guest, #16131) [Link]

How would the Iranian government (which seems to have replaced the Chinese as the traditional bad guy in these kind of plots) impersonate the root?

The only credible opponent in this game is the US government, which through coercion, legal or otherwise, openly or not (National Security letters, anyone?), could influence any of its subjects. But as I understand it the KSK can only be got at by corrupting three individuals, with most of them living outside the US of A -- see http://www.root-dnssec.org/tcr/selection-2010/ for your list of targets.

If the NSA wants to spy on your google.com traffic it is altogether more likely that they would attack com's key via rubber hose techniques, which is probably not as well-protected.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 20:48 UTC (Thu) by job (guest, #670) [Link]

"The government" does not handle the root. ICANN does, and while they are under legislation controlled by the USA government they are very throughly watched by a number of interested parties.

Let's not go overboard with paranoia here. DNS is centralized by design, and most end users would not even notice if SSL was stripped by a DNS-forging middleman so we need to secure it anyway.

Yes, ICANN is a single point of failure in the DNSSEC system -- but we have the opportunity here to replace a system which amounts to multiple points of epic fail.