Hacker News Reader

Comment by Seenso | Hacker News Reader

> Firefox DoH is snake oil, plain and simple...

Correct me if I'm wrong, but the concern I have about browser-controlled DoH is that it seems like it could make it harder for a tech-savvy user to assert control over their own network. IIRC, most network-level ad-blocking operates at the DNS level. I've also personally blocked telemetry by setting my router's DNS proxy to resolve certain telemetry servers to 0.0.0.0. It's my understanding that DoH would bypass that. Couple that with Google's planned neutering of Chrome's ad-blocking API, and it seems like it will become increasingly hard for end-users to avoid ads.

And the fact that DoH uses HTTP seems like it would make it impractical to block as a protocol.

I think I would have preferred an encrypted DNS protocol that ran on its own port, at least.

View on HN

For existing configurations, it makes it a bit trickier to implement. If you ad the aforementioned rules to your DNS and/or IP block list, then Firefox will default back to using the system configured DNS.

But DoH is not targeting ad-blocking specifically, but rather intermediaries that are outside of the local network. There is evidence of ISPs injecting traffic (Comcast/Xfinity) or selling user traffic (AT&T) and this was designed to close one of the last gaps for a fully encrypted flow.

It's possible to setup a DoH server for your local network's DNS resolver, so that all of your traffic leaves your network encrypted, even if not encrypted on your local network.

Firefox tries to recognize some personalized DNS servers and prefer them to DoH in cases where it finds them. The FAQ here suggests that work is ongoing and they are hoping tech-savvy DNS alternatives used for things like parental controls and ad blocking meet them somewhere in the middle in terms of making it easier to Firefox to auto-disable DoH when a user has explicitly opted in to more power user configurations.

Similarly related is the general idea is that if you have the tech savvyness to setup a PiHole in the first place, you should be able to find the Firefox settings on your devices to disable DoH, and Firefox isn't hiding those settings, they are just trying to make a default that is better for more people (the folks that aren't tech savvy and have a different threat model than the power user with a PiHole or similar).

> you should be able to find the Firefox settings on your devices to disable DoH,

You should be able to find a buried config option to regain your privacy is _not_ a position that we should consider acceptable!

There are serious logistical challenges keeping the option off even at a household level.

At the moment it isn't difficult to block at the network level, but presumably they'll start evading those blocks eventually or otherwise the claim that this is intended to prevent monitoring by ISPs will seem pretty hollow.

Mozilla seems to have made it clear that where DoH is on by default the config option won't be "buried", particularly because out of the box multiple options will be provided (both Cloudflare and NextDNS). That you see it as "regain" says we probably have different threat models/assessments here, I'm not sure I can help you much further with the paranoia associated with your current threat model.

Paranoia? What exactly is paranoid about being concerned about the browser sending all firefox users traffic for an entire nation to a single party which has the technical ability to monitor all this traffic and under which current norms have essentially zero protection under the law?

Surveillance at large providers is an unambiguous fact, centralizing all user's traffic at one makes it tremendously easier.

The majority of US broadband users are on comcast, which as reported-- in spite of stinking in many respects has made similar public commitments to cloudflare to not monetize this data.

I think you likely have it reversed which threat model is more fringe and which is more concerning.

> At the moment it isn't difficult to block at the network level, but presumably they'll start evading those blocks eventually or otherwise the claim that this is intended to prevent monitoring by ISPs will seem pretty hollow.

Have you considered using a different browser? One that aligns more with your values?

If you use the nextdns DoH provider in Firefox you can actually configure your own adblocking domains even when you're moving around across networks. Just FYI

> If you use the nextdns DoH provider in Firefox you can actually configure your own adblocking domains even when you're moving around across networks.

Uh. Doesn't this prove that Firefox's DOH implementation is sending strong per-user identifying information to the server?

That’s what nextDNS offers (basically pihole in the cloud). And that only works by hitting a specific subdomain or endpoint on nextdns.io.

If you’re hitting cloudflare, it’s just hitting the regular endpoint so no user identifying information.

Ah. Thanks! Makes sense.

If you configure a personal NextDNS URL as the DoH provider then unsurprisingly NextDNS will know that URL was used, and personalise things accordingly.

If you use Firefox's defaults but pick NextDNS from the list, you don't get personalisation as NextDNS has no idea who you are.

A nice thing about DoH here: For DNS over TLS NextDNS has to hide the configuration ID in the hostname, which as a result is revealed in SNI, but for DoH they can put it in the path and so it is encrypted like everything else.

> ...for DoH they can put it in the path and so it is encrypted like everything else.

Wait: You mean to say URLs are encrypted? I thought not. There must be a reason why GET requests aren't used for secret-sharing, for instance, as opposed to POST. What am I missing?

An HTTPS URL has several parts, let's look at them in turn from left to right of a URL https://userinfo@someserver.example:1234/foo/search?term=goo...

The scheme will always be HTTPS and that isn't sent anywhere but it's implied.

The userinfo (often empty) is encrypted and delivered to the server. This could be login credentials but in the modern web it's largely unused.

The hostname someserver.example is delivered to the server unencrypted using SNI (Server Name Indication) before encryption switches on. This is used to enable virtual hosting - the server may behave differently depending on which name you want. The Encrypted SNI work (eSNI) at the TLS Working Group intends to standardise a way to encrypt this information - note that if your IP address only serves one single web site the hostname doesn't give much extra away so eSNI is mostly interested to bulk hosts, the cloud and so on.

The port 1234 is not delivered anywhere but it's implied since the connection will use this TCP port.

The path /foo/search is encrypted, this is the part NextDNS uses to distinguish one customer from another if you use their custom URLs rather than the built-in default in Firefox.

The query parameters ?term=goose are encrypted

The fragment identifier #egg is not sent to the server this is used only locally in the browser engine itself.

The reason you shouldn't design web sites to use GET for secrets is that URL ends up in the user's URL bar and gets bookmarked or shared with friends.

Thanks for the detailed reply. Appreciate it.

Reply on news.ycombinator.com