4 ms·

I'm wondering if there could be an equivalent DNS entry that might help signal a site should only be accessed via SSL? Then you could possibly protect against i

I'm wondering if there could be an equivalent DNS entry that might help signal a site should only be accessed via SSL? Then you could possibly protect against initial access as well as returning users.

agl 14y ago
We can't do a blocking DNS lookup other than for A/AAAA records. About 5% of Chrome users cannot resolve TXT records because the network is filtering the DNS requests. (i.e. we know that the network is up and we're asking about a DNS name that we known exists, but we get a timeout.)
- peterwwillis 14y ago
  Think this is a side-effect of EDNS0 being blocked, or UDP packets on port 53 bigger than 512 bytes being blocked?
  - agl 14y ago
    The response is 345 bytes and we used the OS DNS library to send the request, so I'm not sure whether EDNS0 would have been set.
- sadpluto 14y ago
  In [1] you showed us how to authenticate via DNSSEC HTTPS in Chrome. If I understand correctly this involves a lookup of a TYPE257 record. Given that only 5% can resolve TXT records, do you know what % of Chrome users can then resolve TYPE257 records? 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 http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
  - tptacek 14y ago
    No. The whole idea of HSTS is that you can never trust the DNS; you assume that's the most likely way an attacker is going to MITM her victims. HSTS tells the browser to remember that from that point on, all connections to SERVER.NAME have to happen under a TLS session with a valid cert.
    - sadpluto 14y ago
      Thanks for your answer! I'm more confused by the moment about DNSSEC et al: isn't the DNSSEC-based validation of HTTPS referred to above supposed to get rid of CAs in the future? That wouldn't make sense even with DNSSEC considering that the information is not encrypted? (Right?) I hope you don't take this as "hijacking", but I'd be most curious about what you and other security experts think about Paul Vixie's "Whither DNSCurve?" [1], which has amazingly not been submitted in HN. I just submitted it [2]. (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 http://www.isc.org/community/blog/201002/whither-dnscurve [2] http://news.ycombinator.com/item?id=4268461 http://news.ycombinator.com/item?id=4268461
      - tptacek 14y ago
        There is a splinter group of people- who- want- DNSSEC who argue that DNSSEC will obviate the need for CAs. There reasoning, distilled, is that DNSSEC is itself a PKI, with the roots signing TLDs and TLDS signing domains and so on. Since the core architecture purpose of certificates is to "break the tie" between an attacker's public key and the real site's public key, and since DNSSEC zones could serve the same purpose, by housing a DNSSEC-signed public key, blammo, no more Verisign. 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.
peterwwillis 14y ago
DNSSEC could allow this to work, if the connection between the client and a DNSSEC-enabled recursive resolver were secure. But if you're on the LAN of the client (for example, a wireless network) you can spoof every DNS response and the client is boned.
- tptacek 14y ago
  ... at the cost a myriad of other annoyances, breakages, and potential insecurities after DNSSEC is deployed. Deploying DNSSEC to help with the problem that HSTS is trying to solve is like deploying Homer Simpson's automatic hammer to pin an announcement to a bulletin board.
  - peterwwillis 14y ago
    It's still one possible solution to the problem. If one's windows dns client were a DNSSEC-validating stub resolver[1], and you believe that in the future we will come to a point where network admins stop fucking with DNS traffic for no good reason, they could authenticate information from the website's dns on first-visit and avoid HSTS's pitfall. Note that I never said this was going to be practical :) [1] https://www.internetsociety.org/deploy360/resources/dnssec-trigger/ https://www.internetsociety.org/deploy360/resources/dnssec-t...

agl 14y ago

We can't do a blocking DNS lookup other than for A/AAAA records. About 5% of Chrome users cannot resolve TXT records because the network is filtering the DNS requests. (i.e. we know that the network is up and we're asking about a DNS name that we known exists, but we get a timeout.)

peterwwillis 14y ago
Think this is a side-effect of EDNS0 being blocked, or UDP packets on port 53 bigger than 512 bytes being blocked?
- agl 14y ago
  The response is 345 bytes and we used the OS DNS library to send the request, so I'm not sure whether EDNS0 would have been set.
sadpluto 14y ago
In [1] you showed us how to authenticate via DNSSEC HTTPS in Chrome. If I understand correctly this involves a lookup of a TYPE257 record. Given that only 5% can resolve TXT records, do you know what % of Chrome users can then resolve TYPE257 records? 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 http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
- tptacek 14y ago
  No. The whole idea of HSTS is that you can never trust the DNS; you assume that's the most likely way an attacker is going to MITM her victims. HSTS tells the browser to remember that from that point on, all connections to SERVER.NAME have to happen under a TLS session with a valid cert.
  - sadpluto 14y ago
    Thanks for your answer! I'm more confused by the moment about DNSSEC et al: isn't the DNSSEC-based validation of HTTPS referred to above supposed to get rid of CAs in the future? That wouldn't make sense even with DNSSEC considering that the information is not encrypted? (Right?) I hope you don't take this as "hijacking", but I'd be most curious about what you and other security experts think about Paul Vixie's "Whither DNSCurve?" [1], which has amazingly not been submitted in HN. I just submitted it [2]. (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 http://www.isc.org/community/blog/201002/whither-dnscurve [2] http://news.ycombinator.com/item?id=4268461 http://news.ycombinator.com/item?id=4268461
    - tptacek 14y ago
      There is a splinter group of people- who- want- DNSSEC who argue that DNSSEC will obviate the need for CAs. There reasoning, distilled, is that DNSSEC is itself a PKI, with the roots signing TLDs and TLDS signing domains and so on. Since the core architecture purpose of certificates is to "break the tie" between an attacker's public key and the real site's public key, and since DNSSEC zones could serve the same purpose, by housing a DNSSEC-signed public key, blammo, no more Verisign. 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.

peterwwillis 14y ago

DNSSEC could allow this to work, if the connection between the client and a DNSSEC-enabled recursive resolver were secure. But if you're on the LAN of the client (for example, a wireless network) you can spoof every DNS response and the client is boned.

tptacek 14y ago
... at the cost a myriad of other annoyances, breakages, and potential insecurities after DNSSEC is deployed. Deploying DNSSEC to help with the problem that HSTS is trying to solve is like deploying Homer Simpson's automatic hammer to pin an announcement to a bulletin board.
- peterwwillis 14y ago
  It's still one possible solution to the problem. If one's windows dns client were a DNSSEC-validating stub resolver[1], and you believe that in the future we will come to a point where network admins stop fucking with DNS traffic for no good reason, they could authenticate information from the website's dns on first-visit and avoid HSTS's pitfall. Note that I never said this was going to be practical :) [1] https://www.internetsociety.org/deploy360/resources/dnssec-trigger/ https://www.internetsociety.org/deploy360/resources/dnssec-t...