3 ms·

Why bother securing your DNS from eavesdropping when an eavesdropper can easily tell what sites you're visiting based on your other IP traffic? It seems OpenDN

by trotsky 15y ago

Why bother securing your DNS from eavesdropping when an eavesdropper can easily tell what sites you're visiting based on your other IP traffic? It seems OpenDNS is interested in this technology only as far as it deflects from people being interested in DNSSEC, an ietf standard. Why don't they care for DNSSEC? Because it either discourages or prevents DNS poisoning or hijacking (depending on how you set up your client) and Open's business model relies on hijacking NXDOMAIN DNS responses to serve ad filled pages.

tptacek 15y ago
Confidentiality isn't the killer feature/flaw here; integrity is. DNSSEC is a design-by-committee debacle. It's a good thing to have options here. I'm a broken record on DNSSEC on HN; a decent starting point might be: http://news.ycombinator.com/item?id=2078488 http://news.ycombinator.com/item?id=2078488 (Goals of DNSSEC v. DNSCurve) http://news.ycombinator.com/item?id=1523704 http://news.ycombinator.com/item?id=1523704 (Bunch of things I think are wrong with DNSSEC)
- deleted 15y ago
  [deleted]
- FaceKicker 15y ago
  > Confidentiality isn't the killer feature/flaw here; integrity is. I initially posted "Authentication, too" in response to this, but then I reread the page and it says it doesn't provide authentication. ...in which case, I don't really understand this at all. What good is integrity if there's no authentication? Doesn't that mean an active network attacker can completely swap out the DNS response for a different one, but just can't modify it (short of creating a brand new one)? If that's the case, it seems completely useless. It claims to protect against man-in-the-middle attacks, but I don't understand how that's possible if there's no authentication. I'm sure I'm missing something here.
  - tptacek 15y ago
    DNSCrypt is a DNSCurve implementation. DNSCurve is manually keyed; "the administrator publishes the server's public key along with the server's address", which is effectively shorthand for "static keying is left as an exercise for the reader". You can't MITM a DNSCurve request, because it's encrypted and signed using a pair of static keys.
    - FaceKicker 15y ago
      Signed using a pair of static keys? So...it is authenticated then? Or are they more like SSH keys/self-signed certs where you just trust the key belongs to who you think you're talking to the first time?
      - tptacek 15y ago
        SSH is an authenticated protocol. The trust anchor scheme SSH uses is "key continuity". The same model has been proposed as a replacement for TLS CA certs. DNSCurve doesn't specify a key management scheme, but to the extent you want to call a bunch of web pages on Bernstein's site a "spec", it specifies "static keys". Static keys are a perfectly viable trust anchor scheme; like they say about routing, "if you can get away with it, the best protocol is static".
        mike-cardwell 15y ago
        The trust anchor scheme SSH uses is "key continuity" There is also RFC4255 which allows people to publish fingerprints of their SSH server public key in DNSSEC secured "SSHFP" RRs. If you have a resolver which supports DNSSEC, you can run this command: ssh -o "VerifyHostKeyDNS yes" grepular.com You wont be prompted to verify the fingerprint as usual, because OpenSSH will already have done that verification using the DNS. You also know for sure that grepular.com has resolved to the correct IP address. There is also "VerifyHostKeyDNS ask", which just displays the result of the lookup, but still allows you to confirm the fingerprint. DNSSEC allows you to do stuff like this because it secures the integrity of the record all the way from the authoratitive DNS server to the users resolver. There's also DANE (still going through the standards process) which allows you to publish a fingerprint of your SSL certificate on a domain/port basis, in DNSSEC secured DNS. If you install a Firefox addon named "Extended DNSSEC Validator", visit https://grepular.com/ https://grepular.com/ and click the lock button to the left of the address bar, you will notice it says: "Domainname is secured by DNSSEC and the certificate is validated by CA and DNSSEC" This is because I'm following the latest draft of the DANE protocol. Will be nice when the spec is finalised and browser support becomes native. I don't like that any CA can currently generate a cert for my domain. Another benefit that DNSSEC brings is with PKA records. I publish a record in the DNS which contains a URL to my public PGP key, and its fingerprint. You can automatically download my key and encrypt something using it by typing: gpg --auto-key-locate pka -ear mike.cardwell@example.com Replacing "example.com" with "grepular.com". Because I also have DNSSEC set up on my domain, if you have a DNSSEC supporting resolver, you know that the fingerprint you've received hasn't been tampered with on the way. Of course, somebody could compromise my DNS server or the end users resolver. I'm not claiming that DNSSEC is a perfect solution. All I'm saying, is that the integrity that it provides to DNS lookups is massively valuable. By the way, I wrote a long article about setting up DNSSEC on Monday: https://grepular.com/Understanding_DNSSEC https://grepular.com/Understanding_DNSSEC [edit] I forgot to mention the "Certificate Stapling" functionality built into Chrome now. https://dnssec.imperialviolet.org/ https://dnssec.imperialviolet.org/ uses a self signed certificate, but Chrome users wont get any notification about that because of the tech described here: http://www.imperialviolet.org/2011/06/16/dnssecchrome.html http://www.imperialviolet.org/2011/06/16/dnssecchrome.html [edit2] Another benefit I forgot to mention. I use third party DNS slaves for redundancy. Because I'm using DNSSEC, those third parties can't serve up different records to the ones I configured, either on purpose or because they've been compromised. Well, they could, but DNSSEC supporting resolvers would just SERVFAIL the modified responses.
munin 15y ago
the only thing better than one way to authenticate DNS queries is N ways to authenticate DNS queries! "standards are great everyone should have some" snark aside, I guess it's nice to see someone really stepping forward and giving a crap about cryptographic authentication of DNS? the DNSSEC people don't seem to care that much and are perfectly willing to move at glacial speeds on implementation ...
- tptacek 15y ago
  That's not a fair summary of what's happening at all. DNSSEC advocates would certainly like to accelerate DNSSEC adoption. Unfortunately, they've fallen into a design that: * failed architecturally twice before reaching its current state (it is being, as Richard Stallman would put it, debugged into existence) * required signin from multiple huge corporations to begin deployment, so much so that some (well known) DNSSEC proponents have unironically proposed alternate privately run roots just to get things kickstarted * requires the maximum amount of re-education from DNS operators everywhere, being as it is a standard that imposes even greater levels of config complexity than HTTPS/TLS, but on a DNS record by DNS record basis * is effectively a no-op in the current DNS architecture, where your desktop doesn't run a bona fide cache but instead delegates that task to a cache server (the thing you call a "DNS Server" in your Internet configuration, but which on reflection turns out to be something no Internet host actually needs if they're willing to run their own cache) --- because it only protects server-to-server traffic, and architecturally can't protect stub-to-server traffic. * Will require upgrades to every "sockets"-style program ever written to properly function. If a magic wand existed that could dispel any of these issues, I assure you that the IETF working group would wave that wand right away.
nogui 15y ago
DNS is only the beginning. The easy to understand, free crypto "framework" that underlies DNSCurve (~DNSCrypt) can be applied to any service: HTTP, SMTP, etc. That framework is not an OpenDNS creation. It was written by university professors and it's in the public domain. DNS is simply the first service to try it out on. Maybe because DNS is rather important, since so many other services depend on it. Users need to decide what is important to them. A. Having cryptographically signed DNS information as a means to authenticate it. B. Having protection against people sniffing or tampering with your traffic, e.g. your DNS requests, on the wire. C. Or both. A. The best way to avoid cache poisoning is to refrain from using someone else's cache. Using your own cache, accessible to you only, alleviates the need for DNSSEC as a means to combat cache poisoning. B. But how many alternatives to the fast, strong crypto that underlies DNSCurve are there? Are they as fast for use in this way? C. "Securing DNS" is an _ambiguous_ description. As such, it can mean at least two different things. Two of those things are addressed by DNSCurve and DNSSEC, respectively. From a functional perspective (i.e. in terms of what they do), they are not in competition with each other. They each address different things. But because we use the amibiguous idea of "securing DNS", the user has to decide what "securing DNS" means: A, B or both? The IETF, DNSSEC hype and OpenDNS's deceptive business model are all red herrings. Users simply need to decide what is important to them. A. Are they concerned they're not getting the right IP addresses for the domain names they inquire about, because the source for DNS info they're using is not dependable? (e.g. it's a shared cache like OpenDNS and can be poisoned) B. Or are they more concerned someone is sniffing and possibly tampering with their DNS traffic, in transit? C. Or both?

by trotsky 15y ago

tptacek 15y ago

Confidentiality isn't the killer feature/flaw here; integrity is. DNSSEC is a design-by-committee debacle. It's a good thing to have options here. I'm a broken record on DNSSEC on HN; a decent starting point might be: http://news.ycombinator.com/item?id=2078488 http://news.ycombinator.com/item?id=2078488 (Goals of DNSSEC v. DNSCurve) http://news.ycombinator.com/item?id=1523704 http://news.ycombinator.com/item?id=1523704 (Bunch of things I think are wrong with DNSSEC)

deleted 15y ago
[deleted]
FaceKicker 15y ago
> Confidentiality isn't the killer feature/flaw here; integrity is. I initially posted "Authentication, too" in response to this, but then I reread the page and it says it doesn't provide authentication. ...in which case, I don't really understand this at all. What good is integrity if there's no authentication? Doesn't that mean an active network attacker can completely swap out the DNS response for a different one, but just can't modify it (short of creating a brand new one)? If that's the case, it seems completely useless. It claims to protect against man-in-the-middle attacks, but I don't understand how that's possible if there's no authentication. I'm sure I'm missing something here.
- tptacek 15y ago
  DNSCrypt is a DNSCurve implementation. DNSCurve is manually keyed; "the administrator publishes the server's public key along with the server's address", which is effectively shorthand for "static keying is left as an exercise for the reader". You can't MITM a DNSCurve request, because it's encrypted and signed using a pair of static keys.
  - FaceKicker 15y ago
    Signed using a pair of static keys? So...it is authenticated then? Or are they more like SSH keys/self-signed certs where you just trust the key belongs to who you think you're talking to the first time?
    - tptacek 15y ago
      SSH is an authenticated protocol. The trust anchor scheme SSH uses is "key continuity". The same model has been proposed as a replacement for TLS CA certs. DNSCurve doesn't specify a key management scheme, but to the extent you want to call a bunch of web pages on Bernstein's site a "spec", it specifies "static keys". Static keys are a perfectly viable trust anchor scheme; like they say about routing, "if you can get away with it, the best protocol is static".
      - mike-cardwell 15y ago
        The trust anchor scheme SSH uses is "key continuity" There is also RFC4255 which allows people to publish fingerprints of their SSH server public key in DNSSEC secured "SSHFP" RRs. If you have a resolver which supports DNSSEC, you can run this command: ssh -o "VerifyHostKeyDNS yes" grepular.com You wont be prompted to verify the fingerprint as usual, because OpenSSH will already have done that verification using the DNS. You also know for sure that grepular.com has resolved to the correct IP address. There is also "VerifyHostKeyDNS ask", which just displays the result of the lookup, but still allows you to confirm the fingerprint. DNSSEC allows you to do stuff like this because it secures the integrity of the record all the way from the authoratitive DNS server to the users resolver. There's also DANE (still going through the standards process) which allows you to publish a fingerprint of your SSL certificate on a domain/port basis, in DNSSEC secured DNS. If you install a Firefox addon named "Extended DNSSEC Validator", visit https://grepular.com/ https://grepular.com/ and click the lock button to the left of the address bar, you will notice it says: "Domainname is secured by DNSSEC and the certificate is validated by CA and DNSSEC" This is because I'm following the latest draft of the DANE protocol. Will be nice when the spec is finalised and browser support becomes native. I don't like that any CA can currently generate a cert for my domain. Another benefit that DNSSEC brings is with PKA records. I publish a record in the DNS which contains a URL to my public PGP key, and its fingerprint. You can automatically download my key and encrypt something using it by typing: gpg --auto-key-locate pka -ear mike.cardwell@example.com Replacing "example.com" with "grepular.com". Because I also have DNSSEC set up on my domain, if you have a DNSSEC supporting resolver, you know that the fingerprint you've received hasn't been tampered with on the way. Of course, somebody could compromise my DNS server or the end users resolver. I'm not claiming that DNSSEC is a perfect solution. All I'm saying, is that the integrity that it provides to DNS lookups is massively valuable. By the way, I wrote a long article about setting up DNSSEC on Monday: https://grepular.com/Understanding_DNSSEC https://grepular.com/Understanding_DNSSEC [edit] I forgot to mention the "Certificate Stapling" functionality built into Chrome now. https://dnssec.imperialviolet.org/ https://dnssec.imperialviolet.org/ uses a self signed certificate, but Chrome users wont get any notification about that because of the tech described here: http://www.imperialviolet.org/2011/06/16/dnssecchrome.html http://www.imperialviolet.org/2011/06/16/dnssecchrome.html [edit2] Another benefit I forgot to mention. I use third party DNS slaves for redundancy. Because I'm using DNSSEC, those third parties can't serve up different records to the ones I configured, either on purpose or because they've been compromised. Well, they could, but DNSSEC supporting resolvers would just SERVFAIL the modified responses.

munin 15y ago

the only thing better than one way to authenticate DNS queries is N ways to authenticate DNS queries! "standards are great everyone should have some" snark aside, I guess it's nice to see someone really stepping forward and giving a crap about cryptographic authentication of DNS? the DNSSEC people don't seem to care that much and are perfectly willing to move at glacial speeds on implementation ...

tptacek 15y ago
That's not a fair summary of what's happening at all. DNSSEC advocates would certainly like to accelerate DNSSEC adoption. Unfortunately, they've fallen into a design that: * failed architecturally twice before reaching its current state (it is being, as Richard Stallman would put it, debugged into existence) * required signin from multiple huge corporations to begin deployment, so much so that some (well known) DNSSEC proponents have unironically proposed alternate privately run roots just to get things kickstarted * requires the maximum amount of re-education from DNS operators everywhere, being as it is a standard that imposes even greater levels of config complexity than HTTPS/TLS, but on a DNS record by DNS record basis * is effectively a no-op in the current DNS architecture, where your desktop doesn't run a bona fide cache but instead delegates that task to a cache server (the thing you call a "DNS Server" in your Internet configuration, but which on reflection turns out to be something no Internet host actually needs if they're willing to run their own cache) --- because it only protects server-to-server traffic, and architecturally can't protect stub-to-server traffic. * Will require upgrades to every "sockets"-style program ever written to properly function. If a magic wand existed that could dispel any of these issues, I assure you that the IETF working group would wave that wand right away.

nogui 15y ago

DNS is only the beginning. The easy to understand, free crypto "framework" that underlies DNSCurve (~DNSCrypt) can be applied to any service: HTTP, SMTP, etc. That framework is not an OpenDNS creation. It was written by university professors and it's in the public domain. DNS is simply the first service to try it out on. Maybe because DNS is rather important, since so many other services depend on it. Users need to decide what is important to them. A. Having cryptographically signed DNS information as a means to authenticate it. B. Having protection against people sniffing or tampering with your traffic, e.g. your DNS requests, on the wire. C. Or both. A. The best way to avoid cache poisoning is to refrain from using someone else's cache. Using your own cache, accessible to you only, alleviates the need for DNSSEC as a means to combat cache poisoning. B. But how many alternatives to the fast, strong crypto that underlies DNSCurve are there? Are they as fast for use in this way? C. "Securing DNS" is an _ambiguous_ description. As such, it can mean at least two different things. Two of those things are addressed by DNSCurve and DNSSEC, respectively. From a functional perspective (i.e. in terms of what they do), they are not in competition with each other. They each address different things. But because we use the amibiguous idea of "securing DNS", the user has to decide what "securing DNS" means: A, B or both? The IETF, DNSSEC hype and OpenDNS's deceptive business model are all red herrings. Users simply need to decide what is important to them. A. Are they concerned they're not getting the right IP addresses for the domain names they inquire about, because the source for DNS info they're using is not dependable? (e.g. it's a shared cache like OpenDNS and can be poisoned) B. Or are they more concerned someone is sniffing and possibly tampering with their DNS traffic, in transit? C. Or both?