| |||||||||||||
Fraudulent *.google.com certificate issuedFraudulent *.google.com certificate issuedPosted Aug 30, 2011 17:16 UTC (Tue) by dkg (subscriber, #55359)In reply to: Fraudulent *.google.com certificate issued by dlang Parent article: Fraudulent *.google.com certificate issued 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.
(Log in to post comments)
Fraudulent *.google.com certificate issued Posted Aug 30, 2011 18:44 UTC (Tue) by raven667 (subscriber, #5198) [Link]
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]
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]
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]
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:
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.
|
|||||||||||||