How to keep your ISP’s nose out of your browser history with encrypted DNS | Hacker News Reader

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

arstechnica.com

531 pointsazizuysal186 comments

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.

Well if you’re using a VPN then your ISP can’t see much. Some VPNs offer DNS too.

Same argument applies there then. Your VPN provider can already see what websites you're visiting, so use their DNS servers if you can. Don't add yet another third party.

The problem currently is that they aren't getting warrants!

I've spoken to some folks that worked in the VPN provider industry... many of them aren't the bastion of consumer protection they claim/are perceived to be. With the exception of Tor (and even that has been found to have problems) I'm not sure "single-point" anything will really provide you with anonymity.

I think it really comes down to your threat model though and what tradeoffs you're willing to accept for anonymity (e.g. captchas, performance, etc).

I think the sweet spot for CloudFlare's offering is if you're in a country or service provider that takes liberties in overriding DNS responses.

Buy VPS and install your own VPN. It's much harder to spy on you in this setup and basically requires complicated targeted attack. I'm not sure if common networking setups for VPS record TCP connections, if they do, then VPS provider can record some important metainformation, but it's still not a lot. On the other side with VPN it's much easier to spy on every client.

Sure, however any warrant can get billing data from your hosting provider, or your credit card company will resolve directly to you.

But if your VPS is in a country that's not very friendly to your country, getting data from the hosting provider won't be easy.

I mean, if you’re trying to defend against a coordinate government attack, you’re boned anyway. They’ll just break into your house and install a sniffer, or arrest you, or make your life hell.

That’s assuming they can’t just get into your home network through zero days, which an individual has no practical defense against.

Well seeing as all credit cards are basically subject to US law, you'd need to find a VPS that is going to accept say Bitcoin for server space. Perhaps one that is going to accept cash in the mail.

Then hope that said provider is reputable enough to be up to date on their security, and honest enough not to just cave under pressure.

Realistically the VPS solution fails simply because there is no obscuring of traffic. We all know that security through obscurity isn't real security. However if a VPN provider has 1,000 users using their IP block than any specific traffic is harder to isolate to one user. -- Presuming they are honest and not keeping logs.

Running your own VPS means that all traffic is owned by you.

there's a huge difference between anonymity when someone is looking for you and anonymity in general.

As you've mentioned, if someone wants to track you through Tor, that's still potentially possible. But that's a completely different ballgame than "My ISP wants to track every last website I visit so they can pair that with my address/billing info to sell to advertisers". I don't think my ISP is going to go through all the hoops to find my Tor exit node, just so they can sell that to advertisers. Passive onlookers can be untrustworthy too.

The shades on my windows keep people from seeing me change, but if someone really wanted to see specifically me naked, they could probably enter my house and make the shades useless.

I still consider the shades useful.

VPN is just a remote ISP.

Of course you have more options, but it's not TOR.

Edit: I mean TOR only figuratively.

There are Tor exit nodes which monitor traffic see:

https://boingboing.net/2016/07/01/researchers-find-over-100-...

If the traffic is https, in theory they can't link any of that traffic to individuals.

If a party were to, by chance, to monitor both your entry and exit nodes couldn't they match the traffic by time & packet size, et al? Then use known techniques to match pages accessed (it's something like 85% accuracy IIRC).

That would match to individual IP, or potentially an individual if you're logged in.

So? What if the VPN doesn’t know who you are? What if it’s your own VPN but others don’t know that?

The entire point of choosing a good VPN is to get the visible data off of your immediate ISP, since they know who you are, and into a more nebulous net, where others do not.

This is a great way of thinking about a VPN, and how I describe it myself. If you have limited options on your choice of ISP, then a VPN allows you to expand your choices (excluding speed, latency, usage caps).

Some of us have no use for our ISP's DNS servers, due to government-mandated cencorship.

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

I'm in the same boat. My ISP's DNS servers tend to be very slow and often unresponsive. As a result I've used googles (a bad idea, in retrospect) for the last 10 years or so.

> I've used googles (a bad idea, in retrospect) for the last 10 years or so.

That is a reasonable consideration, but Google is very specific about how they use and retain data collected by Google Public DNS. Assuming they are not lying, I don't think it's a significant concern. (Admittedly, their policy is not as good as Cloudflare's "no IP logging" policy.)

https://developers.google.com/speed/public-dns/privacy

TL;DR: Logs with IP addresses are deleted within 48 hours; permanent logs keep city-level location data, but no personally identifiable information. "We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services."

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.

>Then switch ISPs.

Hahahha, and then he said "Then switch ISPs", like we have more than one high speed choice where we live".

Then vote for politicians that help with that.

Due to laws designed for more broadband competition, I've got over 6 providers to choose from here in Germany.

They want a solution today, not in 20 years.

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.

https://tools.ietf.org/html/draft-huitema-tls-sni-encryption

There's domain fronting [1] and http/2 certificate frames [2] - they are conceptually similar.

[1]: https://www.bamsoftware.com/papers/fronting/

[2]: https://tools.ietf.org/html/draft-bishop-httpbis-http2-addit...

both of them seem to use the concept of "connect via a fake domain name, then connect to the real domain". i'm not sure how this is scaleable for everyday browsing. you might be able to find the fronting server for wikipedia, but how are you going to find the fronting server for every website you're visiting? this solves the problem of censorship, but not the problem of ISP surveillance.

Couldn't the client send SNI after the DH and then the server authenticate the secret? That way MITM would always be detectable at least.

> Couldn't the client send SNI after the DH and then the server authenticate the secret?

That means you can't use sni to route your request to a different server.

Yes, whatever is serving on that interface will have to terminate TLS. Or somehow pass the session information to the proxied server, or ask the client to reconnect, or do some kind of tls tunneling from the client to the real host. I don't think any of those are unreasonable options.

What if we could have first class SSL certs for IP addresses? You connect to the IP and verify the cert it presents you with your PKI, then switch to the desired host via SNI or some other mechanism after DHE is established. I suspect you could do this without any extra hops but I haven't really thought through how that would work.

tls certificates already work out of the box for ip addresses (at least on firefox, see https://1.1.1.1/), so that's actually a pretty neat solution.

> What if we could have first class SSL certs for IP addresses?

They're not routable.

What does this mean?

What's the next hop for a cryptographic hash? With IP addresses, you have a heirarchy: You match on a prefix to find the router to handle the next path, and that one matches on a longer prefix to find the next hop, and so on.

That allows you to have routing tables that don't include every single host on the internet. This is what allows efficient routing to happen.

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

The point is you don't know what the public key of the target website is. You find out by asking for it, and then you verify it's authenticity by checking the signature. Before you connect all you know is the domain and the keys of CA's you trust.

Ah, right. Thanks.

> But that’s vulnerable to MITM

It is if that’s all you’re trusting, but you get to check the validity of the cert, so someone could MITM a TLS 1.3, but it wouldn’t do them much good as all they would get is a request for a certificate, then the normal TLS certification steps must proceed. Without the certificate private key the rest of the handshake would fail.

sure, they're not going to MITM your http connection, but they will be able to MITM your certificate connection, which allows them to discover what site you visited, which is the same problem that SNI has.

They can do this, but your browser would retroactively notice that it happened and go "holy shit that was bad, you should complain to someone about it". This does not solve for all threat models, but it does avoid the "snoopy ISP".

There's nothing good about breaking DPI. Instead of blocking a single site you'll end up blocking entire IP address. I'd even suggest an optional extension of HTTPS which allows to put entire URL as unencrypted part of the request. Censorship systems usually block content by individual pages. Currently with HTTPS it's not possible to block individual page, so an entire website is blocked.

That would be such a bad idea, lots of websites send data that should be secret on the query parameters.

TLS and HTTP are different things. TLS is being used without HTTP in lots of cases.

Besides, even if such extension had existed it would've been easy to write X in TLS header and Y in the HTTP payload to circumvent the ban, like the domain fronting[1] trick currently being used by e.g. Signal.

[1] https://en.wikipedia.org/wiki/Domain_fronting

Services like google share IPs amongs their services. If SNI was encrypted, youtube.com could not be blocked unless the entire IP space of google is blocked (which would be very hard to do since nearly everyone relies on gmail).

Kazakhstan blocked major part of gmail functionality at one point of time. You couldn't download attachments, images didn't work, may be something else. I think they tried to block blogspot. but shared IP broke gmail. It was broken for months, nobody really cared except people pointlessly ranting on forums. Those, who needed working email, migrated to other providers or used proxy. I'd like to live in the world without censorship but I don't see this happening, so I'd prefer to minimize censorship damage at least.

Getting rid of plaintext SNI won't help much.

The domain is there in the certificate itself. There are, of course, some (or maybe many, I don't have statistics) certificates for multiple domains (wildcard and alt. name), but still.

> The domain is there in the certificate itself.

With TLS 1.3, the certificate is in the encrypted portion of the handshake.

That's nice to hear. I stand corrected, thank you.

However as I understand the protocol the very first step of the TLS 1.3 handshake, the nonce generation, can be MiTMed sufficiently to allow an attacker to determine the target domain. It's only in the next step that server and client do authentication.

The attacker can't trivially continue the handshake beyond that point but that might give enough info to log the attempt and terminate the connection.

Or just connect up a second connection and see what certificate they send back.

We’re working on it.

(for the lazy: eastdakota's profile claims to be the CEO & co-founder of CloudFlare)

Thanks & very, very good luck!

He is

This is fantastic and amazing to hear. Thank you!

Russian here. Entries in gov's blacklist of sites should include IP addresses, domain names and optionally URLs. SNI isn't that helpful for ISPs because they could block traffic by IPs rather using DPI (IIRC only one NIR is using it, but for DNS rather than TLS itself).

For sites like google, blocking IPs would meet resistance.

This situation is covered with a whitelist of IPs and domains (year ago it became official after exploitation of vulnerability in how blacklist register works, before it was on ISPs, Youtube was banned by some ISPs quite a few times), including .google.com, .youtube.com and other Alphabet's domains, *.facebook.com and some others.

So effectively, if you post something on Blogger it cannot be taken down, because the whole Google would come down with it.

Still, encrypting SNI hides quite some information (were you searching, watching youtube, reading blogger, was it image search, maps...?)

Rechecked the list, only https://*.youtube.com and (whooping) .google. are inside [0]. [0]: https://storage.googleapis.com/smisc/%D0%A1%D0%BF%D0%B8%D1%8...

SNI is just an ugly hack because IPv6 is not deployed widely.

You could have a server listen on a subnet and clients randomizing its target IP.

Datacenters today work differently: IPs convey a fuzzy idea of where to find what you are looking for. Server name will be used to route your request internally in the DC.

I cannot imagine exposing the IPv6 IPs of single racks: it makes the whole "cloud" thing fall apart.

If thats true it’s because of the limitations of IPv4 more than anything else. With a single $5/month machine from Linode you have a /64 IPv6 subnet, that is 2^64 IP addresses just for that one machine.

You don't need to. This is no different than how lack of SNI is handled with IPv4, just have multiple static IP addresses on whatever frontend you're using. With IPv6 it's easy to delegate as many IP addresses as you want. The slight problem with this is that it doesn't solve the privacy problem at all as now you just look at the IP address and check which domain it serves.

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.

Depends a lot. My ISP's (both mobile ISP and DSL) have pretty slow DNS providers. My mobile connections were significantly quicker after I switched to using VPN with Cloudflare DNS as resolver (or even the local resolver, though that is normally a bit slower than Cloudflare/Google DNS due to caching)

Not every DNS query is going to be followed by a HTTP or HTTPS connection. You also have queries for other protocols; queries which are never followed by a connection because the response was "this name doesn't exist"; "leaked" queries for internal hostnames; queries which were just to check if a name exists; and reverse (PTR) queries.

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.

TLS 1.3 mandates it, doesn't it? It's safe to say it's near enough to 100% (of clients sending) to not be worth mentioning outliers like yourself.

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 introducing roundtrips, and disclosing the hostname unencrypted at least once on the wire.

"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

When you say "If the server responds with hostname not found", what are you talking about? Exactly which protocol are you refering to when you say "hostname not found" ?

Most web servers will just fall back to the default virtual hosts SSL certificate if no SNI header is present in the clients request... They don't reply "hostname not found", or "nope, no such host", or anything similar...

"They don't reply "hostname not found", or "nope, no such host", or anything similar..."

"hostname not found" was meant to be a general term for failure due to not sending the correct servername when it is required, not a specific protocol error. I apologise for not being more precise. What happens with the non-SNI clients I use in the rare case when absence of correct servername is fatal is that the connection fails. (Most times a correct servername, let alone any servername, is not required1 and the connection succeeds. Thats the point of the original comment: in a majority of cases, its possible to get the page content without using SNI.)

1 As in the case of example.com, for example.

However, I use a local forward proxy for TLS-enabled websites. The proxy returns HTTP 503 error when the connection fails due to SNI. Thus, I do get a consistent "server response" when this happens, albeit not from the remote server.

Since the ClientHello is sent in the clear, a MITM can simply reset the connection until the client retries with SNI. Again, there is no generally useful way to solve this

"... a MITM can simply reset the connection until the client retries with SNI."

That doesnt happen when I fetch https://example.com without sending a servername in ClientHello.

For the majority of TLS-enabled websites on the internet, that does not happen. I get the page content just fine witout sending a servername in ClientHello.

But I should send the servername in ClientHello anyway?

This reasoning I am too stupid to understand.

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

True, although what are they going to do with the data? If it’s primarily for selling to ad companies, a tiny slice of privacy minded people aren’t worth much.

ISPs want to sell advertising, or data to advertisers. Why bother trying to advertise to a few geeks who are probably running PiHole anyway? Especially since doing that multiplies the hardware requirements 100 fold.

Possibly because the people who you can sell that data to are prepared to pay way more per "product" than the people trying to sell you fast moving consumer goods or ICO de jour...

Wouldn't surprise me at all to find there's a market where intelligence services can purchase lists of TOR users - for example...

Err, snooping on a teen visiting "naughty" sites isn't exactly interesting from any perspective.

Nah. DNS caching would prevent you from seeing every usage of the site. Much better to just log every source ip : dest ip.

IPs are shared, they don't necessarily tell you what site you're accessing.

Never thought of virtual hosts as a security feature! But, I guess it is!

IMHO, very few things the ISPs and their advertising customers care about would be using shared IPs.

The only thing you'll see is a list of CDNs and cloud providers.

I suppose that is true for smaller sites that don't have their own IP addresses but for larger sites you will be easily able to map it through reverse DNS.

Probably only for the very large. And even there I'm not sure if you can distinguish amazon from AWS, Microsoft from Azure and Google from Google Cloud. Facebook and Twitter should work reliably but even with a Facebook IP it could probably still be Instagram or Whatsapp.

Data mining is big money. They can glean in insane amount of personal information about you based on the sites you go, aside from the fact they already know who you are.

That is true in my case, but my ISP has in the past redirected various queries to their landing/search pages, which means that I simply don't use them anymore.

Not every site uses SNI. Most probably do not. Not every site uses custom DNS for their CDN, either.

Your ISP knows way less about you if you avoid their DNS. And they are the only ones that know your legal name and billing address, usually.

SNI is part of the first message a TLS client sends to the server - the Client Hello. TLS clients that support SNI (including all modern browsers) will typically always send the SNI extension, regardless of whether the server supports or makes use of SNI.

That's why I use IE6: for Privacy reasons.

So if I make an ssh tunnel and use a remote DNS, my ISP can still log requests? How?

That's not what the article is proposing. Still, your home ISP may not be able to, but the ISP of the machine you're SSHing into can.

It is a social issue. Would you trust the government of Holland or would you rather try your chances with the Turkish government?

With the new legislation that's coming I absolutely wouldn't trust the Netherlands anymore... Something like Denmark seems like a better alternative.

What's the new legislation to be wary of? For the benefit of those using Dutch hosting services...

If what you say is true -- on top of that, your ISP can also (in theory) fingerprint you as someone who is avoiding their DNS servers.

We have to plug many holes, encrypted DNS plugs one, encrypted SNI will plug another.

What about running your own DNS server locally?

Your requests will go to the root dns servers, which then go the dns servers of the domains you request. But also it will cache responses locally (so if you make another request it won't even need to make an external request).

Yes your ISP can still see it but they can see all your traffic anyway.

Standard DNS is clear text. It doesn't matter if you use your ISP DNS server or not. Either way, they will see the DNS traffic.

Forward you DNS requests to servers using DNS with TLS encryption or with a VPN provider. That way the DNS requests can't be seen by your ISP.

Using a non-ISP DNS server isn't enough.

I'm not a 'networking' person, but am I wrong in believing a VPN would (potentially, with caveats) prevent your ISP from "being able to see which IPs you're sending packets to"? Wouldn't all packets look like they are going to and from the VPN?

As mentioned, that doesn't get around the VPN knowing where your traffic is going, and there are issues such as your VPN dropping and your system switching over as opposed to dropping the packets, compromising your privacy.

correct, only VPN connection visible to ISP, no content

sshuttle 0.0.0.0/0 --dns -r $server

don't forget --dns ;)

Kind of strange that Google's first result for "sshuttle" is a dead project (literally says "Wrong project!" in the title) that links you to the real one.

That won't work. All the ISP has to do is snoop port 53 and they can see your DNS whether you're using their DNS server or someone else's. You have to get the DNS traffic out of their visibility by using VPN or DNS TLS.

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 is made first which would be sniffable?

Not stupid. It makes it harder for the ISP (just grabbing and reading DNS traffic is a very convenient way of getting this information), but it's still visible if they look at all your connections. IPs alone aren't great (e.g. CDNs conflate a lot of domains under one IP), but if they look inside the traffic they can still get the full domains.

Also TLS SNI transmits the hostname in plaintext at the start of the TLS handshake.

It increases the cost and complexity of an ISP tracking you, which is a win within itself. Plus some services share public IPs or are behind a global cache (e.g. Cloudflare) making it harder to pinpoint exactly which endpoint you tried to access.

Is it perfect? No. It is better than yesterday? Yes.

I call these "micro-wins." One micro-win won't make a difference, but two, three, four, and so on eventually start to have an impact. And that's all we can hope for.

Even often cited VPNs just shift the problem downstream. Instead of your ISP monitoring you, the VPN provider themselves could, or if you host it yourself then your server/virtual server's ISP could. VPNs themselves are another "micro-win" but people often claim they're a complete bulletproof solution.

Not sure why you're being downvoted; as tescos says here in the UK, every little helps :)

>"I call these "micro-wins."

I like this term :)

It's also believe its a win when computer privacy and security begin to edge into main stream lexicon. Somewhat anecdotal but I recently saw that NordVPN is advertising on CNN.

Unencrypted SNI is still the global standard for TLS, and it is supported by most commerical tracking software. Tracking complexity has not been increased in practice.

These are valid points. Encrypted DNS stops your ISP from sniffing DNS requests, but does not directly stop them from seeing IP based traffic, and potentially deducing the domain name, if that IP address is from a suitably unique source. (Shared hosting might thwart this somewhat.)

The slightly bigger problem is HTTPS with SNI, which leaks the host header in plain text before establishing the connection. It's an unfortunate necessity as long as hosting providers need to use virtual hosts behind a shared IP address, but it's also one more potential snooping vector to deal with.

> ...how does using encrypted DNS prevent your ISP seeing what websites you go to?

It doesn't do this by itself. It just prevents one method of data collection.

The ISP can easily connect your IP to your subscriber information, and their DNS can log every lookup made by your IP. Even if you use another DNS, since it's unencrypted, they can (and likely do) sniff that traffic and collect the same information.

> Can't ISPs still see the eventual target IP address, and do a reverse DNS lookup of that?

Sure, but this requires a slightly higher level of effort, and also assumes that you're not connecting to a CDN, which can make your requests pretty opaque.

> Even with HTTPS/TLS I thought encryption is done after a handshake isn't it, which would imply a TCP level connection is made first which would be sniffable?

Right, and even with SNI, the requested hostname is still sent in the clear. I hope this will be fixed somehow in future implementations. In the meantime, if you need to treat your ISP as absolutely hostile, then you need a VPN or some other kind of encrypted tunnel or proxy.

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 without encrypted DNS.

> 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

Just to add another point I don't see mentioned. For sites hosted on godaddy like shared hosting plans it makes it a lot harder because a single IP frequently resolves to a dozen or so actual sites.

How many sites being visited fit this model? Fewer everyday, but it seems a lot of non-mainstream content is still hosted on smaller shared hosting plans.

Even if not actually on shared hosting, there's a fair chance the site will be behind a shared CDN (e.g. CloudFlare). Doesn't really help while SNI is in the clear, but it's a start.

Also mentioned in article: Use DNSCrypt Proxy V2 (a golang rewrite) for DNS over TLS and/or DNScurve https://github.com/jedisct1/dnscrypt-proxy

E.g. on a Mac with Homebrew. First:

    brew install dnscrypt-proxy

Second: Edit your /usr/local/etc/dnscrypt-proxy.toml and put e.g. google or cloudflare there inside

Third: Put your DNS to 127.0.0.1

I'm a bit concerned about using it yet because it was written from scratch just about three months ago and probably hasn't gone through enough testing.

How about an actively-maintained 3-year-old project? [0]

[0] https://github.com/alterstep/dnscrypt-osxclient

I used that one before. I don't like it technically. It only supports DNScurve and installs itself deeply into the system (e.g. system preferences). I also think it's more unreliable because they don't do the caching in a good way (sometimes a DNS server fails is my experience). I like dnscrypt proxy V2 more because it's more rock solid, works better on caching and also supports DNS over TLS. Only downside on dnscrypt proxy is that you don't have a nice UI and you have to type the local DNS 127.0.0.1 manually into your Wifi or LAN connection point.

I use this as an UI for dnscrypt-proxy v2: https://getbitbar.com/plugins/Network/dnscrypt-proxy-switche...

Not maintained any more.

A new macOS GUI would be really great.

I'm using this daily and it's rock solid. Good job there

I used it on my route (netgear with oss firmware) works great.

This preoccupation with ISPs is akin to concern about a pin prick while blood gushes out of knife wound unattended.

All sorts of solutions are offered enthusiastically while the elephant in the room, tens of thousand of engineers and billion dollar companies incentivized to hoover up and collate every minutiae of user data as a business model, is met with hand wringing and apologism about ad revenue.

In this case solutions have to emerge from outside the tech community by something like GDPR. Given that reality and the primacy of ad driven business models in SV its difficult to contextualize this preoccupation with ISPs. It feels like a distraction, insincere and driven by commercial concerns.

I agree. To play devil's advocate you can choose not to use Facebook or Gmail or Android. In many areas (of USA) there's exactly two choices for Internet access, and in some there's only one. Additionally the quid pro quo of free online services for personal data may be considered less objectionable than additional monetization on top of the monthly fee.

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 have no reason to trust your VPN provider more than your ISP.

A lot of people really do distrust their ISP enough that even with knowledge that you're shifting the responsibility to the VPN provider they still trust a random VPN more than their ISP.

Would I trust some random unknown VPN provider more than Comcast? Maybe.

I would trust the Russian mob before I would trust Comcast

Well, as in anything human it is a matter of incentives. Comcast probably has an incentive for logging and selling your data to advertisers, whereas the Russian mob probably has other, more pressing things to worry about.

I follow the same logic by setting up my own VPS in a rented $big_provider VPN. VPS companies are succulent targets that surely attract many eyes, whereas I doubt any non-state actor has the capacity of capturing and filtering the traffic of the millions of random VPNs that $big_provider has.

Its better than no solution, and you aren't limited to using one VPN. A dozen VPN providers each with 8% of your browsing history is still bad, but far preferable to an ISP with 100%.

Is it? I would guess that people already split their traffic between a home workstation connected through a local ISP, a mobile phone connected through a national carrier ISP, and a work computer that is connected with a (third) enterprise ISP. The concerns that linger in the comments here, are about the dangers of exposing even a slice of your metadata can be disastrous.

Therefore, going from three to eight ISPs is arguably worse as your exposed to nearly 3x the risk of exposure.

The more information any one entity has about any individual, the more accurate a profile they can create. The more thinly spread your metadata is, the harder it is for any one corporation to create a profile. Clearly there is no perfect solution, it depends on what sort of privacy risks you are trying to mitigate.

I mean, by this logic I have no reason to use Cloudflare's DNS server more than my ISP's, because, 'hey, technically Cloudflare could be lying about their logs.'

Yeah, my VPN provider could be lying to me and logging a whole bunch of extra data under the table. But I know my ISP is logging that data. I have every reason to trust a paid VPN provider more than my ISP because my VPN provider is basing their business model on me trusting them, not on being a monopoly.

Not to mention that VPNs also help at least a bit with anonymizing IP addresses. The trust model I have with directly exposing my IP to a website is "I hope nobody I visit on the Internet is logging this."

If I'm wrong and my VPN is logging everything, I'll still be in a better position than I was with my ISP, because at least I won't be broadcasting my current physical location to every single website I visit.

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.

But unless you work at the VPN provider you don't have enough information to make that choice. You can't tell from the outside whether the VPN provider is logging or not.

For many ISPs, I think we have sufficient grounds for trusting the ISP less than a decent VPN provider.

It is a social consideration. Would you trust the government and jurisdiction of Holland or would you rather use DNS services offered by Turkey?

To answer this question, location is pretty much key.

If in the Netherlands: probably Turkey. If anywhere else: probably the Netherlands.

Although it is hard to think about a scenario in which the only available choice is between the Netherlands and Turkey.

The idea is hedging against the closest guy with a stick.

I wonder when someone is going to take on the task of figuring out how to encrypt SNI

https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02

I cannot begin to understand how is it better to reveal your DNS access patterns to the global company like Cloudflare, as opposed to revealing them to your local ISP?

Who do you think can smoother monetize your data - your local ISP or Cloudflare? Or maybe Cloudflare solemnly promised never to do it?

If an effort is to be taken, the best thing is to run your own DNS resolver that will query root servers and follow the chains directly.

I assume it has something to do with how easy it is to connect your data with other aspects of your identity. Presumably with an ISP it is associated with the name of the subscriber, whereas there is some chance with other DNS servers that this is untrue.

It's fragmenting the data - CloudFlare _only_ gets your DNS data, whereas your ISP has DNS, content of non-HTTPS traffic (Cloudflare gets a non-zero percentage of this anyway), billing information, real identity etc. Your ISP can _immediately_ tie your DNS records to a real identity (or a member of your household at the very least), whereas CloudFlare can only make inferences from the data and the source IP location. It gives two companies an incomplete picture, rather than one knowing EVERYTHING. CloudFlare promise to not do so is also a non-zero consideration - it's clearly unenforceable/you would never know, but the mere promise is probably better than many ISPs.

I'd also say most users' ISPs are probably are global companies (or at least national) anyway.

> the best thing is to run your own DNS resolver that will query root servers and follow the chains directly

Only if the first step is also encrypted. If it is plain DNS, then your ISP can see the requests almost as easily as if going to their own servers (or transparently redirect the requests to their servers).

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

DNS over HTTPS (DoH) works in the latest Firefox Nightly: https://facebookexperimental.github.io/doh-proxy/tutorials/f...

DNS Lookup has its own protocol that doesn't work with https. If you send an https request to a DNS server, even if you include all the other parameters required for a DNS lookup, you won't get back a usable response (unless the server has been setup to proxy DNS requests over https, but this comes at a speed cost and increases your server overhead, so it is very uncommon - I've never heard of this happening. edit: apparently 1.1.1.1 supports this)

+1 for asking, though. Nothing wrong with trying to learn more about something you know very little about. Not sure why others are downvoting you.

1.1.1.1 supports DNS over HTTPS (and TLS). You generally need a local tool running though which acts as a local resolver and does the DNS lookups for you (using HTTPS).

Just using 1.1.1.1 is going to be unencrypted DNS. If you trust cloudflair they claim to delete logs after a short period.

Using DNS over HTTPS which you can leverage in the latest Firefox nightly will make your DNS queries over a HTTPS website service. This will prevent your ISP or anyone else from tracking your DNS queries (besides cloudflare of course).

As tomcooks said, you can't directly add https to a DNS server address in your settings and have it work.

However some DNS providers support the new standard DNS-over-HTTPS (including Google and Cloudflare). Some also support the alternative new standard DNS-over-TLS (including Cloudflare).

While support for these encryption methods support is offered by some DNS providers, your client devices may or may not support the new encryption methods. Firefox is currently implementing DNS-over-HTTPS so at least Firefox DNS requests will be soon able to use it and Google is currently beginngin to implemen it in Android. The new encryption methods are still in Draft status so expect to see adoption increase as they near completion.

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?

While I'm not everybody, I think its decent and better than the default which is your ISP. Normally pointing directly at google or cloudflare does not hide it from your ISP. I actually just did this yesterday though not with a raspberry pi since I just care about my windows box for now and my router is not open enough to allow this. I think they recommend doing it on your router directly if possible. This helps with Android devices for instance which do not really let you set your DNS easily. I installed DNSCrypt for windows on my desktop and pointed at cloudflare. As others pointed out without a VPN, its only kinda helpful but I figure I don't need to share any more than I really need to with my ISP who I don't trust in general. Also I figure even with VPN anything that slips past the VPN for whatever reason is leaked less to my ISP.

Had an extra benefit of creating a log file of queries so I can see addresses that are being queried. I found NordVPN pinging random websites and wondering why? (To see if I'm blocked apparently)

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.

Your traffic still has to go to those servers, so your ISP still can track the terminal server IP, can't it? (TOR, or tunneling aside)

An almost unlimited number of domains can be hosted off a single IP. That said, the SNI header can still be sniffed on an HTTPS connection.

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

Unless you are using encrypted DNS, I'm not how that helps -- even using your own resolver, your ISP can sniff the content of the requests (though it might be a legal rather than a technical hurdle -- they can only legally monetise requests that go to their servers -- depending on jurisdiction?).

After all these posts, I still don't get what is the problem with the ISP seeing my DNS queries. That's still private telecom information protected by law. Unless you're doing something obviously illegal, and are under investigation. They can't do anything with that data legally. Using Cloudflare or VPN most likely won't solve the problem anyway, at least if you're doing something criminal enough. Therefore claiming it making you untraceable on net, is snake oil anyway.

Why are so many clients still running stub resolvers?

Just type "apt-get install unbound" already. You won't miss that 200 kB resident memory.

...Or one could just run one's own DNS servers.

Yes, it isn't that hard to do:

https://www.digitalocean.com/community/tutorials/how-to-conf...

It is not much about privacy, but about the integrity of your data.

Your ISP can see the IP addresses and all the meta data for your traffic. With the current way DNS is setup, they can modify the responses and re-route you any where they want.

With HTTPS and encrypted DNS, it makes a lot harder for them to inject content or redirect you without browsers warnings.

Isn't there an option to polute the information the ISP sees to such a level that their information is useless?

E.g. contact a friendly service that gives back N different random domain names; then lookup those domain names, spread over, say, an hour; then repeat.

Then you connect to one and boom, isp knows who you connected to.

I just realized I'm obfuscating my internet usage inadverently. Here's how:

Good source of reasonable randomness is twitter. I've set up a scrapper for various twitter accounts and I'm downloading every page that is linked by those accounts automatically.

With this approach you can even select what you want to look like based on your browsing data by selecting proper accounts. Gold bug? Bitcoin fool? Knitting expert? No problemo. ;)

The problem with pollution ideas is you're still giving your real information to your monitors. You can never be certain they won't find a way to discard the fake information and keep the real.

Now we just need a an encrypted DNS provider that isn't NSA's puppet...

Namecoin?

does/can Pi-Hole use encrypted DNS?

I have a raspberry-pi on my home network running Pi-Hole and my router’s DHCP server gives all devices on my network the Pi-Hole as the DNS address

It doesn't have built in support for it since it's just using dnsmasq under the hood, but you can install something like dnscrypt-proxy and then configure pi-hole (i.e. dnsmasq) to use it as its upstream DNS server.

Yes, you can follow the instructions from the wiki https://github.com/pi-hole/pi-hole/wiki/DNSCrypt-2.0

Now if we can just get a default encrypted email protocol....

I thought the reason that these critical infrastructures are not encrypted after decades and decades of use is that there are powerful agencies who want to snoop on them.

This is the first I've heard of cloudflared (aka Argo). It's a DNS over HTTPS proxy. As far as I know Firefox is working to get DNS over HTTPS into Nightly so it can be used directly in the browser, but this proxy allows your whole system to use DNS over HTTPS without having to change anything (other than pointing /etc/resolv.conf or equivalent at 127.0.0.1). Pretty cool!

Reply on news.ycombinator.com