5 ms·

For all the attention that https gets, I'm amazed how little (relatively speaking) attention plaintext dns gets. If a site is https then even if an attacker is

For all the attention that https gets, I'm amazed how little (relatively speaking) attention plaintext dns gets. If a site is https then even if an attacker is MITM-ing DNS to their own site they presumably won't have a valid cert for the site they're intercepting, although it has happened many times before, and 50% of the internet is still unencrypted. But even assuming that doesn't happen it's still a huge privacy/data leak.

marcosdumay 10y ago
> If a site is https then even if an attacker is MITM-ing DNS to their own site they presumably won't have a valid cert for the site they're intercepting Kinda. It still can add a CNAME there, and make you go into another site for what it has a valid cert.
- JoshTriplett 10y ago
  A CNAME isn't a redirect; if you add a CNAME record from thing1.example.net pointing to thing2.example.com, the browser still uses the domain name thing1.example.net for certificates, and just does a DNS lookup on thing2.example.com.
  - jsmthrowaway 10y ago
    Put another way, a CNAME literally says the answer for any record type for thing1. is found by querying its canonical name, thing2. They're most comparable to symlinks. There is no data for this label; ask over there in that label. (This is why you can't CNAME the top of a zone, because you need SOA and NS there and CNAME can't coexist with other types. It wouldn't make sense.) In most DNS stacks when an application asks for thing1. the usual way (something like gethostbyname), the resolver side will quietly follow a CNAME answer and resolve thing2. without telling the application anything happened. It's not part of the usual APIs, but that's not to say applications can't find out if desired. Same story with symlinks, where one uses a different API to read the link instead of the target. So for the browser case mentioned, a naive resolver wouldn't even be aware of the CNAME, hence the CN not changing for TLS purposes and the address bar staying the same. No modern browser has a naive resolver, just saying. People trip up on this a lot, just clarifying.
stonogo 10y ago
None of the commercial entities involved stand to gain from providing encrypted DNS lookups. It would just be one fewer bullet point in their personal-data sales packages.
- davidu 10y ago
  I do, which is why I drove the creation of DNSCrypt.
fukusa 10y ago
As far as I understand this doesn't encrypt communication but authenticates it to ensure it hasn't been tampered with. So it's still out in the open. I also don't understand what the benefit over DNSSEC is. Edit: Nvm, DNSSEC still has to trust the validating resolver, DNSCrypt solves this.
- robertcope 10y ago
  dnscrypt is an encrypted channel back to the DNS server. They can tell it's going to OpenDNS because of the IP address, but the cannot see the payload.
  - fukusa 10y ago
    Good to know, couldn't find that on their website.
  - lsjdfkljdfwkwdf 10y ago
    Why would you forward to opendns with a local dnssec enabled resolver? Just implement dnssec and run a proper dns infrastructure. No DNS operator reading HN? This thread is full of misinformation.
- sliken 10y ago
  Right, but what advantage does DNSCrypt have over a local DNSSEC aware resolver? If you can't trust the local resolver you have more serious problems than DNS.
  - bluejekyll 10y ago
    As others have stated, DNSSec only solves for authenticity of the data, not privacy. DNSCrypt has been designed to both authenticate, authorize and encrypt the channel. Using both in conjunction means that you have a private connection with authenticated data coming from the upstream resolver. Now the obvious issue is you don't know what the upstream resolver does with that...
  - tptacek 10y ago
openasocket 10y ago
> But even assuming that doesn't happen it's still a huge privacy/data leak. Meh, if an attacker can sniff your packets, they can already tell what IP addresses you're talking to, which certainly narrows down which domain names you're talking to. I'm far more concerned with the possibility of intercepting or hijacking http traffic. Sure, an attacker could do this with any non-TLS connection in theory, but it's way way easier to hijack that one DNS response and change the A record.
- wslh 10y ago
  The IP address does not always tell you to which site you are connecting to. Many different sites can point to the same IP, more when services like Cloudflare are being used.
  - 0xxon 10y ago
    Most clients nowadays sent the "server name indication" (SNI) TLS extension though, which contains the name of the site you are connecting to. The extension is sent unencrypted, even when using TLS 1.3. So everyone sniffing the traffic can tell where you are surfing to, even without DNS.
    - tedunangst 10y ago
      I don't think many people know this, or at least never think about it. "https means encrypted, that means secret."
    - MertsA 10y ago
      And in order to support clients that don't support SNI, you need to have one domain per IP address so an attacker can just try and connect to that IP and then look at the SSL cert that's sent back to get the domain name.
      - pixl97 10y ago
        >And in order to support clients that don't support SNI There is little reason to support clients that do not support SNI. By supporting those clients you are likely putting your entire encrypted infrastructure at risk. SSL3 should be disabled by now. XP clients are legacy and should be taken out back and shot. Older mobile phones are enormous security risks.

marcosdumay 10y ago

> If a site is https then even if an attacker is MITM-ing DNS to their own site they presumably won't have a valid cert for the site they're intercepting Kinda. It still can add a CNAME there, and make you go into another site for what it has a valid cert.

JoshTriplett 10y ago
A CNAME isn't a redirect; if you add a CNAME record from thing1.example.net pointing to thing2.example.com, the browser still uses the domain name thing1.example.net for certificates, and just does a DNS lookup on thing2.example.com.
- jsmthrowaway 10y ago
  Put another way, a CNAME literally says the answer for any record type for thing1. is found by querying its canonical name, thing2. They're most comparable to symlinks. There is no data for this label; ask over there in that label. (This is why you can't CNAME the top of a zone, because you need SOA and NS there and CNAME can't coexist with other types. It wouldn't make sense.) In most DNS stacks when an application asks for thing1. the usual way (something like gethostbyname), the resolver side will quietly follow a CNAME answer and resolve thing2. without telling the application anything happened. It's not part of the usual APIs, but that's not to say applications can't find out if desired. Same story with symlinks, where one uses a different API to read the link instead of the target. So for the browser case mentioned, a naive resolver wouldn't even be aware of the CNAME, hence the CN not changing for TLS purposes and the address bar staying the same. No modern browser has a naive resolver, just saying. People trip up on this a lot, just clarifying.

stonogo 10y ago

None of the commercial entities involved stand to gain from providing encrypted DNS lookups. It would just be one fewer bullet point in their personal-data sales packages.

davidu 10y ago
I do, which is why I drove the creation of DNSCrypt.

fukusa 10y ago

As far as I understand this doesn't encrypt communication but authenticates it to ensure it hasn't been tampered with. So it's still out in the open. I also don't understand what the benefit over DNSSEC is. Edit: Nvm, DNSSEC still has to trust the validating resolver, DNSCrypt solves this.

robertcope 10y ago
dnscrypt is an encrypted channel back to the DNS server. They can tell it's going to OpenDNS because of the IP address, but the cannot see the payload.
- fukusa 10y ago
  Good to know, couldn't find that on their website.
- lsjdfkljdfwkwdf 10y ago
  Why would you forward to opendns with a local dnssec enabled resolver? Just implement dnssec and run a proper dns infrastructure. No DNS operator reading HN? This thread is full of misinformation.
sliken 10y ago
Right, but what advantage does DNSCrypt have over a local DNSSEC aware resolver? If you can't trust the local resolver you have more serious problems than DNS.
- bluejekyll 10y ago
  As others have stated, DNSSec only solves for authenticity of the data, not privacy. DNSCrypt has been designed to both authenticate, authorize and encrypt the channel. Using both in conjunction means that you have a private connection with authenticated data coming from the upstream resolver. Now the obvious issue is you don't know what the upstream resolver does with that...
- tptacek 10y ago

openasocket 10y ago

> But even assuming that doesn't happen it's still a huge privacy/data leak. Meh, if an attacker can sniff your packets, they can already tell what IP addresses you're talking to, which certainly narrows down which domain names you're talking to. I'm far more concerned with the possibility of intercepting or hijacking http traffic. Sure, an attacker could do this with any non-TLS connection in theory, but it's way way easier to hijack that one DNS response and change the A record.

wslh 10y ago
The IP address does not always tell you to which site you are connecting to. Many different sites can point to the same IP, more when services like Cloudflare are being used.
- 0xxon 10y ago
  Most clients nowadays sent the "server name indication" (SNI) TLS extension though, which contains the name of the site you are connecting to. The extension is sent unencrypted, even when using TLS 1.3. So everyone sniffing the traffic can tell where you are surfing to, even without DNS.
  - tedunangst 10y ago
    I don't think many people know this, or at least never think about it. "https means encrypted, that means secret."
  - MertsA 10y ago
    And in order to support clients that don't support SNI, you need to have one domain per IP address so an attacker can just try and connect to that IP and then look at the SSL cert that's sent back to get the domain name.
    - pixl97 10y ago
      >And in order to support clients that don't support SNI There is little reason to support clients that do not support SNI. By supporting those clients you are likely putting your entire encrypted infrastructure at risk. SSL3 should be disabled by now. XP clients are legacy and should be taken out back and shot. Older mobile phones are enormous security risks.