Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNSCrypt – A protocol to improve DNS security

dnscrypt.org

Post reply on HN
Print view View original

11–20 of 77 posts

Re: DNSCrypt – A protocol to improve DNS security

#11

Post by wslh »

openasocket wrote: post #6
arkadiyt wrote: post #2

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/…

> 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 wa…

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.

Re: DNSCrypt – A protocol to improve DNS security

#12

Post by 0xxon »

wslh wrote: post #11
openasocket wrote: post #6

Earlier quoted context omitted.

> 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 wa…

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.

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.

Re: DNSCrypt – A protocol to improve DNS security

#13

Post by sliken »

fukusa wrote: post #5
arkadiyt wrote: post #2

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/…

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.

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.

Re: DNSCrypt – A protocol to improve DNS security

#14

Post by jsmthrowaway »

JoshTriplett wrote: post #9
marcosdumay wrote: post #3

Earlier quoted context omitted.

> 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.

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.

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.

Re: DNSCrypt – A protocol to improve DNS security

#15

Post by davidu »

stonogo wrote: post #4
arkadiyt wrote: post #2

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/…

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.

I do, which is why I drove the creation of DNSCrypt.

Re: DNSCrypt – A protocol to improve DNS security

#16

Post by ymhuang0808 »

openasocket wrote: post #6
arkadiyt wrote: post #2

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/…

> 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 wa…

Your viewpoint is like the post "DNSCrypt – Not Fundamental Enough" (2011) from TrendMicro.

http://blog.trendmicro.com/trendlabs-security-intelligence/d...

Re: DNSCrypt – A protocol to improve DNS security

#18

Post by tedunangst »

0xxon wrote: post #12
wslh wrote: post #11

Earlier quoted context omitted.

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.

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.

I don't think many people know this, or at least never think about it. "https means encrypted, that means secret."

Re: DNSCrypt – A protocol to improve DNS security

#19

Post by ac29 »

openasocket wrote: post #6
arkadiyt wrote: post #2

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/…

> 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 wa…

>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.

Honest question: with an increasing amount of sites being hosted via cloud infrastructure, does an IP really let you know if you are talking to Amazon, Google, or Microsoft vs the multitude of sites hosted by AWS, GCP, or Azure?

I'm assuming they use their own infrastructure, but I could be wrong.

Re: DNSCrypt – A protocol to improve DNS security

#20

Post by minitech »

ac29 wrote: post #19
openasocket wrote: post #6

Earlier quoted context omitted.

> 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 wa…

>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. Honest question: with an increasing amount of sites being hosted via cloud infrastructure, does an IP really let you know if you are talking to Amazon, Google, or Microsoft vs the multitude of sites hosted by AWS, GCP, or Azure? I'm assuming they us…

Yes, VPS services will still assign your instance an IP address of its own.
Post reply on HN