Hacker News Reader

Comment by Piskvorrr | Hacker News Reader

[tinfoilhat] Given that Chrome now became Google's weapon against adblocking, how long until it starts refusing to use Pi-hole specifically?

https://news.ycombinator.com/item?id=20044430 [/tinfoilhat]

View on HN

This is the dark side of DNS-over-HTTPs: it prevents the network operator from changing what is received by browsers. Sometimes this is legitimate, as in Pi-hole.

Paul Vixie got very upset when he discovered that his chromecast bypasses local DNS settings to go directly to Google: https://news.ycombinator.com/item?id=19170671

I wouldn't be surprised if soon Chrome defaults to DNS-over-HTTPs direct to base, except for the corporate intranet version. They just need to work out how to deal with wifi captive portals.

The problem is two mutually incompatible use cases:

1) trusted endpoint / untrusted network (laptop in a coffee shop)

2) untrusted endpoint / trusted network (chromecast/alexa/other corporate zombie on your home network)

Which category a given scenario falls under depends on who you ask - to Google, Chromecast is in the first category. I don't know if it's possible to design a system that somehow always favors the rights of the individual.

Damn, this is a good point. Just because of network architecture, ultimately somebody-- either the client or the network-- has to have the Final Word on where DNS requests go, and either way opens people up to attacks depending on the scenario. If the client has the Final Word, you can't stop your Chromecast from talking to 8.8.8.8; if the network has the Final Word, you can't trust DNS on foreign networks or use your own resolver.

> I don't know if it's possible to design a system that somehow always favors the rights of the individual.

This is why people keep objecting to technological solutions to social problems. Adblocking is a stopgap technological solution (although very effective at the moment); properly protecting the rights of the individual requires a social and legal process.

I disagree. Technical solutions are largely preferable. Political solutions are feeble and can be changed on a whim.

If the NSA has the capability to sniff vast amounts of network traffic, encrypting that traffic is a much stronger defense than telling the NSA they aren't allowed to deploy the capability for the time being.

If Chrome insists on using its own DNS or removing the adblocking API for add-ons, one can just use another browser like Firefox that has the desired technical capabilities. Managing DNS lookups and HTTP requests are not "stopgap" solutions, they are basic functionality that any one entity can't eradicate.

It's a big concern. I can block DNS on my network (except for pihole), but I can't block QUIC, and certainly not HTTPS or TLS. If I know about an IP ahead of time, I can block those, but who's to guarantee that Google or any other nefarious service would always use a well known IP for DoH?

How would devices use the obscure DoH IPs, there would have to be a method to update/lookup said IPs. That same method could be used to keep an up to date block list.

Alternatively, the traffic could be subject to heuristics to identify DoH connections.

could setup a small firewall (pfSense) that routes all DNS queries from connected devices to your own DNS server.

Not with DNS-over-HTTPs and certificate pinning you can't, because the certificate check would fail.

(That would be a very annoying thing to do in a device or browser, but it's certainly possible)

Exactly, the only choice is to root the device or return it as defective.

How would a web browser know which DNS it's using?

You set your DNS preference to point to the PI-hole and it should behave like any other DNS server. I guess it could attempt to resolve some spam domain like doubleclick.net and if it was incorrect it could complain...

There is a clear and definite trend of taking DNS out of the user's control, see all the hype with DNS over HTTPS etc etc.

Firefox is working on using DoH (opt-in at the beginning, but who knows) from "select" providers. Chrome has a similar switch, surely. Same with Android 9, opt-in DoH, but maybe it'll become opt-out or no-opt in the future.

In the name of privacy and security of course, but with the totally unintended side effect of users unable to dodge ads via DNS/hosts. Interesting, no?

The argument you are making is a huge stretch.. Cloudflare is one of the bigger driving forces for DoH and they have nothing to do with ad revenue. Claiming that DoH is some sneaky way to get rid of things like pi-hole is just ridiculous.

DoH in itself is not sneaky, no more than ping is. The push to centralise DNS resolution in the hands of a few questionable actors is and this is what is happening.

Cloudflare for example would absolutely love to know what you're up to all day; and because they can now correlate data from their "omnipresent" WAF with the data from 1.1.1.1 they could get some interesting information... And believe you me, they're not sending it to /dev/null.

Cloudflare makes a pretty specific statement against what you are saying:

"1.1.1.1 does not mine any user data. Logs are kept for 24 hours for debugging purposes, then they are purged."

Are you claiming they are lying?

I'm all for assuming the people who work there are good eggs with the best intentions, but Cloudflare, Inc. is a U.S. company. As I understand the U.S. legal landscape with regards to data and privacy protection, they could be forced to lie at a moment's notice and not talk about it.

So far as I know there is no legal way for the US to make a company lie about its activities. That is the basis of warrant canaries, which have not been tested in court yet. You can find cloudflares https://www.cloudflare.com/transparency/.

They could be forced to not talk about something via a gag order.

I'm not claiming their lying or doing anything internally that is different. There is just nothing stopping the change from happening, now that the possibility exists

I'm claiming I don't believe them. They could write on their page whatever they see fit and do a completely different thing internally.

> There is a clear and definite trend of taking DNS out of the user's control, see all the hype with DNS over HTTPS etc etc.

It seems absurd that these companies are blurring the line between software and malware.

Software vendors are going to have to start paying for the bandwidth they use on networks against the will of the network operator.

some of their products already have hardcoded Google DNS. see

https://www.reddit.com/r/googlehome/comments/8917ci/google_h...

They could force Chrome to use Google's DNS over HTTPS.

Sure, but what's to stop any application from choosing some other DNS to use?

There was a bit of controversy about FireFox doing exactly that. https://yro.slashdot.org/story/18/08/05/2353249/security-res...

While you're at it, add Blokada to your Android device and it too will eliminate the need for uBlock Origin or Ghostery in Chrome on Android since it's operating outside of the browser's sandbox. Or use Firefox on Android and continue using the ad block plugins it provides. Hopefully Firefox doesn't go away anytime soon...

https://www.xda-developers.com/fix-dns-ad-blocker-chrome/

Conceivably we could take a harder line on this, if we get a little deeper into the routing. We could make it so we only whitelist IP addresses outbound if we saw them come back through our DNS server, and network block everything else. Then if you bypass my DNS server, you don't get to talk to the Internet, unless you directly pick an address that something else has whitelisted that way.

I'm thinking about this, and feeling like the PiHole is a nice start, and I mean that sincerely, not sarcastically or dismissively, but what we need is a whole-house reverse firewall with that sort of capabilities, including everything the PiHole already does. If you did TLS interception, you could also pretty much implement uMatrix at the household level, for instance.

Interesting, interesting. Note that long DNS TTLs will break this: your DNS server needs to hand out artificially short TTLs so that clients will keep re-querying (within the local network).

I was also considering going the opposite direction and given extremely long permissions to the IP in question, i.e., longer than any practical DNS TTL. In general, I'm not too worried about a good IP becoming bad, and if an IP can be both "good" and "bad" this way I'm not going to block it with this technique anyhow. It'd be a potential hole, but if this non-existent project got to the point that it was being that directly targeted, that'd only mean we got pretty successful to even get to that point. :)

I should probably make an explicit point that I left implicit; I'm interested in anyone popping up and telling me "Hey, this thing exists already and it's http://...".

(I find myself wondering if I finally found my Rust project...)

It already does. This is the purpose of putting a DNS-over-HTTPS resolver into the browser, so you can't bypass it with local resolvers.

So you block access to Google's DNS (except for your local DNS server) on your router.

And so the arms race continues.

Couldn't I sign my own pi-hole and add the certificate to my phone/computer?

No use if e.g. Chrome hardcodes Google's servers and ignores the system ones.

Could you hardcode the ip addresses in your own NAT?

This is, in fact, already sometimes necessary since there are things that will hard code 8.8.8.8.

Chrome's future crippled adblocking support is still more powerful than pi-hole.

Reply on news.ycombinator.com