Digressing a bit further, wouldn't you say that even if HSTS is enabled and registered in the all the browsers' built-in list, you still have the problem of unencrypted DNS lookups? (Maybe this kind of attack is orders of magnitude harder to implement. I honestly don't know.)
[1] http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
(If I could vote for your time investment, please kindly consider commenting on that article before replying to this comment.)
Thanks again!
[1] http://www.isc.org/community/blog/201002/whither-dnscurve
There are a bunch of problems with this idea. Most of the ones that spring to my mind are problems with DNSSEC in general: its brittleness, the reliability problems I think it's going to cause, the things it does that actually diminish the security of the DNS... but the big point relevant here is: DNSSEC replaces a market of CAs with a baked- into- the- Internet fiat authority. If DNSSEC had replaced SSL CA's in the mid '00s, Ghaddafi's Libya would have been Bit.ly's CA. This does not seem like a win to me.
I don't think that rent-seeking SSL CAs are as big a problem as many HN users seem to think they are. I think ultimately there's significant expense involved in operating a secure CA, and that relative to their purported value, CA certificates are reasonably priced.
The pressing problem with SSL/TLS is that CAs aren't trustworthy. They are rent-seeking, as expected, but also shoddily operated. The Internet has largely lost faith in the people operating CAs.
Moreover, a decade and a half of browser/CA relationships have left all the major browsers riddled with skeleton-key CA certs run by organization that nobody can really vouch for. As a result, large companies have purchased browser-trusted CA operations, and then used them to do incredibly dubious things. The companies that have been caught doing skanky stuff with their CA keys haven't even been kicked out of the browser CA stores.
As a result, we're left with a situation in which untrustworthy companies can potentially sign certificates for (and thus enable transparent MITM attacks against) critically important sites, like Google Mail. That's an untenable position.
I personally believe (and, yes, hope) that the future of Internet security looks much like today, except with things like Trevor Perrin and Moxie Marlinspike's TACK scheme, to allow security-sensitive sites to overrule bogus CAs, and to allow us to gradually decrease the architectural dependence we have on SSL CAs and start experimenting with more flexible alternatives.
I am not a fan of trying to take the same model that just failed us, but centralizing it and handing it over to the unaccountable groups of people who control the domain name system.
But the important point is that DNSSEC stapled certificates don't need the browser to perform any extra DNS lookups. The certificate itself contains the DNSSEC information and signatures. Since DNSSEC is signed the data can come over any channel; it doesn't have to be port 53.
Unencrypted DNS still leaks the hostname that you're visiting - that's true. However, the destination IP address probably leaks the same information and, if not, we sent the hostname in the clear at the beginning of the TLS handshake! (That's SNI, it allows SSL virtual hosting.)
Please don't take this as an argument. I just want to know where I'm wrong! I just can't get over the idea of pushing at the (justifiably) paranoid level for HTTPS while we still have plain-text DNS... even with DNSSEC!
Wish request: Your thoughts on http://news.ycombinator.com/item?id=4268461.
The key is that the IP address doesn't matter, indeed it shouldn't matter whether the traffic is going over carrier pigeon. You have a name that you wish to connect to, say example.com, and you have some way to send an receive packets. If the other end can prove that they are example.com by means of a certificate then you have a secure connection. How the data gets there and back is immaterial to transport security.
