Live data from Hacker News

How to keep your ISP’s nose out of your browser history with encrypted DNS

arstechnica.com

81–90 of 195 posts

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#81
post #41
post #40

Earlier quoted context omitted.

I'm still pissed off we didn't get encrypted SNI in TLS 1.3 It would've broken so many dpi based censorship systems in countries like Iran, Turkey, and Russia.

how would encrypted SNI work? sure, you can probably do some sort of DHE, but that's vulnerable to MITM, which is why we have certificates to begin with.

> you can probably do some sort of DHE

Could the browser send a symmetric key encrypted in the public key of the target website, as part of the initial challenge?

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#82
post #79

Earlier quoted context omitted.

Not all TLS-enabled websites require SNI. I customised an https client so I dont use SNI unless a website requires it. With all due respect, 100% adoption of SNI seems like some sort of popular myth among certain web forum commenters. Perhaps we should do a survey of all websites found on HN on a given day and publish it. I would bet that the majority do not require SNI.

SNI-enabled browsers send the unencrypted hostname in the initial ClientHello frame. It's the first transaction in the protocol, and it's how the server decides the content of the ServerHello reply. There is no way to detect the ability to avoid SNI, or indeed any sensible and generally useful way to tell if a ServerHello varied according to the ClientHello SNI hostname without probing the server, which entails intro…

"There is no way to detect the ability to avoid SNI..."

Assuming one is using an SNI-enabled browser.

I dont use an SNI-enabled browser to make the first encrypted HTTP request.

In fact I didnt even say I was using a "browser". I said "https client".

For example, one can use an https client that has SNI disabled or which has no SNI code at all, or one can send any string as the servername in ClientHello.1 If the server responds with hostname not found, then retry using SNI and the desired hostname. IME, most TLS-enabled websites do not require SNI.

  1
  exec printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n'|exec openssl s_client -tls1_2 -no_ssl2 -no_ssl3 -ign_eof -connect 93.184.216.34:443 -servername SNI_NOT_REQUIRED

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#83
post #74

Earlier quoted context omitted.

I was addressing "privacy". It sounds like you have other reasons to not use your ISPs DNS servers. Fair enough.

There aren't many ISP DNS servers that aren't garbage in my experience. Most of them don't send NXDOMAIN. Many of them are slower than either Google or Cloudflare despite being theoretically closer.

Then switch ISPs. Mine sends NXDOMAIN just fine, and is with 0.632ms massively faster than what Google or Cloudflare offer.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#84
post #28
post #5

I'm probably being really stupid, but how does using encrypted DNS prevent your ISP seeing what websites you go to? (I haven't done network stuff for many years, and am a bit out of touch with the current stuff). Can't ISPs still see the eventual target IP address, and do a reverse DNS lookup of that? Even with HTTPS/TLS I thought encryption is done after a handshake isn't it, which would imply a TCP level connection…

It's worth mentioning that encrypted DNS is not just about privacy, but also integrity. It's more difficult to intercept or spoof in hostile networks. ISP can still see the target IP address and SNI. The IP address is sometimes meaningful (single website), but not if it's a CDN or a multi-tenant server. The SNI is being worked on (encrypted SNI, ORIGIN frame, CERTIFICATE frame). The point is none of that matters with…

> It's worth mentioning that encrypted DNS is not just about privacy, but also integrity. It's more difficult to intercept or spoof in hostile networks.

That’s why we all have DNSSEC enabled on our domains, right? Right?

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#85
post #44

If you care about privacy, use your ISPs DNS servers. Your ISP can see exactly which websites you're visiting regardless of how you do DNS, thanks to being able to see which IPs you're sending packets to, and thanks to SNI. The only thing you get from adding some third party encrypted DNS service to the mix, is an additional party which can also see what websites you're visiting.

You most likely also get faster DNS lookups by using your ISP's DNS servers.

Not necessarily. Back when I used Comcast I got much faster browsing speeds by using a proxy over a VPN to a linode server, even though that server was in another state.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#86
post #3
post #2

Sadly not really a solution yet for SNI being unencrypted. So while they may not see your DNS query they can just use DPI to capture the sites. VPN is a solution but not always deployable.

VPN is not really a solution because you have no reason to trust your VPN provider more than your ISP.

You usually have a choice of between 1 and 3 ISPs but you can choose from hundreds of VPN services or setup your own on any cloud server. So there is a very good chance you could find someone more trustworthy. Your VPN can exist outside of your legal jurisdiction which could make a huge difference legally.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#87

Dumbass question: is there a difference between setting one’s DNS to https://1.1.1.1 versus 1.1.1.1 unadorned?

I am not a sysadmin but you can't add https:// (or any other prefix) in front of a DNS address. Secure HTTP is a different protocol, suited for web page hosting.

It's actually a thing:

https://developers.cloudflare.com/1.1.1.1/dns-over-https/clo...

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#88

From the article it seems like 'DNS over HTTPS' (DoH), seems to be the winner . Seems the authors best advice is to set up DoH via DNSCrypt Proxy 2, possibly using a raspberry pi to make it easier to manage ur whole network. Do people here agree this is a pretty good approach?

I thought that dnscurve was the method to actually prevent domain snooping. Regardless, I think running your own authoritative dns which updates from root servers is the real way to go.

In the context of DNS, "authoritative" refers to the servers which hold the actual records for a domain.

I think the term you are looking for is a recursive resolver (one that will perform a full name resolution for a client).

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#89
post #80

If you care about privacy, use your ISPs DNS servers. Your ISP can see exactly which websites you're visiting regardless of how you do DNS, thanks to being able to see which IPs you're sending packets to, and thanks to SNI. The only thing you get from adding some third party encrypted DNS service to the mix, is an additional party which can also see what websites you're visiting.

While for absolute privacy this makes sense, from a lazy ISP dev perspective, why log packets/IPs if you can get marketing data straight from your DNS servers? Surely ISPs have taken this easy approach while encryption has been only for fringe users?

On the other hand, if I were a curious and amoral ISP dev - I'd consider the people circumventing the "easy approach" to be _much_ more interesting to snoop on...

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#90
post #84
post #28

Earlier quoted context omitted.

It's worth mentioning that encrypted DNS is not just about privacy, but also integrity. It's more difficult to intercept or spoof in hostile networks. ISP can still see the target IP address and SNI. The IP address is sometimes meaningful (single website), but not if it's a CDN or a multi-tenant server. The SNI is being worked on (encrypted SNI, ORIGIN frame, CERTIFICATE frame). The point is none of that matters with…

> It's worth mentioning that encrypted DNS is not just about privacy, but also integrity. It's more difficult to intercept or spoof in hostile networks. That’s why we all have DNSSEC enabled on our domains, right? Right ?

DNSSEC is orthogonal to this. Its goal is to prove integrity of records between authoritatives and the closest validator. The validator is most often the resolver doing the recursion, not the client. The client can either revalidate all the answers and/or establish a secure channel between the itself and the resolver (with the added privacy bonus). The reason why many clients don't revalidate is because it's time consuming (basically same complexity as recursor), and fragile (recursive operators can work around DNSSEC screwups by adding negative trust anchors), so it's a tradeoff between convenience and risk.

There's an ongoing work to make revalidation easier - the client would basically ask the recursive to not only provide answer, but also a whole trust chain from a known trust anchor (so it would revalidate the answer without additional queries) https://tools.ietf.org/html/rfc7901

Post reply on HN