DNSSEC + Certs As a Replacement For SSL’s Transport Security

Thursday, October 15, 2009

I was talking with id last night, and then shopped this idea around to a couple local OWASP guys, but now I think it’s baked enough to talk about publicly. I make no bones about the fact that I think SSL is almost entirely worthless against a determined attacker who has man in the middle access and is intent on doing harm, and not just passively listening. Passively listening is limited to people who can get access to a valid cert (through MD2/MD5 collisions, through being a CA or hacking a CA, etc… all of which have been proven possible). That’s bad enough, but put into that that the visual cues tell you nothing about site authenticity (leaving EV certs out of this for the time being) and you’re left with a nearly completely broken security mechanism in the browser. You can debate this fact all you like, but what if I don’t care about site authenticity, I just want to do transport security?

An idea we began toying around with is using DNSSEC. Like DKIM, you can put public certs into DNS records that can be queried by any mechanism that wants to use that. By making a change to the way browsers work to look at the DNS record via DNSSEC a few things become possible. Firstly, you can be assured that you are talking to the correct IP address after the negotiation is complete. That is because the DNS record cannot be spoofed (thanks to DNSSEC) and the certificate can prove that the IP you are talking to is really in control because it can verify that it is the owner of the public key. But wait - there’s more!

SSL certs cost money - but that’s because the CA’s infrastructure needs to be supported. In this model, there is no additional weight on any central authority, outside of DNS itself. So you could theoretically kiss the need for expensive certificates goodbye (sorry CA’s your time may have come!). This obviously couldn’t replace SSL certs in day one, or maybe not even for many years, but for internal applications or for when I want to allow all you readers to ensure you are talking to this server, and not another one, that suddenly becomes possible. It also becomes possible for people in 3rd world countries who cannot afford costly certificates to be able to gain transport security in the browser.

Now you’re probably saying - how is this different than a self signed cert. Well, leaving out of it that the CAs are vulnerable, there are dozens of them that can create certs to MITM you - of foreign origins and that they suffer from collisions… there’s still one major difference. The browser intentionally throws a warning with self signed certs, and even if it didn’t I still can’t verify that it’s my self signed cert and not someone else’s without a significant amount of burden placed on the user.

So now you’re probably saying, there are two single points of failure introduced here - the DNS server and the DNSSEC service itself. Why place additional security burdens on the end user? Well, I’d argue that if DNSSEC is broken, we have a much much bigger problem on our hands than we do than if a CA gets broken into even. If we can secure a CA we should be able to secure a DNSSEC service. I’m not worried about that one nearly as much as I am the individual DNS servers themselves. However, remember that their company already relies on DNS. Let’s say they use Godaddy and rely on them to be primary NS. We’ve already been relying on them to provide lookup security for years. The only difference is now they’re using DNSSEC and now we entrust them with the security of the transport.

The reason I like the idea is that it gives the domain the option to choose - pay for an SSL cert that can be MITM’d or get a free DNSSEC domain cert that can’t. I can’t stop someone from trying to make money off this idea and selling EV DNSSEC domain certs, but I see no reason we can’t make a non extended version completely free to all. Consider this a preliminary RFC - flame away!

Original Source:
http://ha.ckers.org/blog/20091015/dnssec-certs-as-a-replacement-for-ssls-transport-security/
Possibly Related Articles:
8224
Vulnerabilities Webappsec->General
SSL Authentication DNSSEC
Post Rating I Like this!