Hacker News Reader

Comment by zamadatix | Hacker News Reader

If you're on current macOS/Windows/Linux/Android/iOS/ChromeOS you probably just want to configure DoH or DoT at the operating system level so it is done system wide. The other half reading this probably want a "how to force disable" guide instead of a "how to" guide. The automatically rolled out browser specific method described in this article is really directed at users that don't know this is even a choice and probably wouldn't have an opinion one way or the other if they did.

Somewhat unrelated but Firefox also supports SOCKS proxying independent of the OS config. Combining this with ssh -D and you can effectively VPN your Firefox traffic out any box you can ssh to, including the DNS requests. This has been both useful for me as a troubleshooting tool and as a simple internet VPN.

View on HN

> Combining this with ssh -D and you can effectively VPN your Firefox traffic out any box you can ssh to, including the DNS requests. This has been both useful for me as a troubleshooting tool and as a simple internet VPN.

You can essentially "VPN" (relay) your in-browser http traffic with just DoH.

Setup a DoH stub resolver to reply with the same ("gateway") IP for all DNS queries, then on the gateway IP, forward traffic by sniffing TLS SNI (http2/http1.1) or snooping the host headers (http1).

This won't / can't work with http3 because defence against ossification (by such middlewares) was one of quic's design goals (http3's underlying transport). You can blackhole all UDP traffic on the gateway though, which should block http3 altogether.

The only real worry is there's no authentication at the gateway. Could impl it with some form of "captive portal", however.

A toy go program I co-authored can act like the aforementioned "gateway": https://github.com/celzero/midway

That's really fun and clever :), I love hacking with network protocols like that. Go or JS(Node/Deno) is also how I usually go about it! Is there any place I can follow you at outside of GitHub?

Thanks :) I'm not as active on other social media. I must also point out that my networking chops are at beginner level. midway is mostly adopted from inetaf/tcpproxy and dlundquist/sniproxy.

> Go or JS(Node/Deno) is also how I usually go about it!

Pretty much my choice of languages too. Deno, especially, is a wonderful alternative to Go. I co-maintain a DoH stub-resolver that runs on Node/Deno: https://github.com/serverless-dns/serverless-dns

Firefox supporting SOCKS proxying (including DNS) is unbelievably useful when combined with Firefox Containers and Containerize.

Can you outline what you do with this?

I believe you can set a different proxy on a per container basis, so you could for example have a VPN container and a work container that send traffic via different places.

Yup

> If you're on current macOS/Windows/Linux/Android/iOS/ChromeOS you probably just want to configure DoH or DoT at the operating system level so it is done system wide.

Indeed. The problem is that a lot of operating systems still don't support it at all yet.

> The other half reading this probably want a "how to force disable" guide instead of a "how to" guide.

Sadly, yes. And the only reason I've heard for this is that they want to be able to censor or surveil traffic from other people's computers.

I'm actually in the "how do I force disable" camp for reasons unrelated to other people's computers.

On my personal network I've got an inside view of my domain that will resolve internal services if you hit the resolver from the inside, this breaks if an external resolver is used and it'd be more work for no real gain to set this up as an internal DoH resolver and make sure clients used that.

On my work laptop I have a similar need for split resolution in many cases, particularly when connecting to customer's networks. I also have an additional need to be using the same resolution flow as their computers when troubleshooting, if one of their DNS servers is misconfigured I'll never see the issue resolving to an external server.

I've not found the browser fallbacks to fully cover the 2 above scenarios and, even for the parts that are covered, I've not seen it be particularly reliable. Particular if you switch networks often.

I've also seen people against browsers pushing users to fewer centralized services but I'm not really in that boat myself, I point DNS to 1.1.1.1, 8.8.8.8 anyways.

That said I run across a lot of customers that don't understand it's easier to build and enforce a proxy config on a managed fleet than to try to play whack-a-mole with every user packet that doesn't match this policy and try to avoid DoH at the network layer as a result. I don't really expect this to change until security auditors stop accepting these implicit policies as meeting requirements. Outside of finance/government that still seems forever away.

> I'm actually in the "how do I force disable" camp for reasons unrelated to other people's computers.

I think you're actually just in the much smaller but perfectly legitimate "how to disable" camp, rather than the evil "how to force disable" camp, since you're not trying to keep someone who wants to use DoH from using it.

> On my personal network I've got an inside view of my domain that will resolve internal services if you hit the resolver from the inside, this breaks if an external resolver is used and it'd be more work for no real gain to set this up as an internal DoH resolver and make sure clients used that.

Do the domains in question resolve to other IPs on the outside, or do they not resolve at all? If the latter, then Firefox will automatically fall back to local DNS when DoH fails to resolve them. If the former, then I can think of three other solutions that don't require disabling DoH altogether: either switch from split-horizon DNS to NAT reflection, configure Firefox to disable DoH for just that domain and its subdomains, or add IPv6 addresses for them since it doesn't get NATted.

> I also have an additional need to be using the same resolution flow as their computers when troubleshooting, if one of their DNS servers is misconfigured I'll never see the issue resolving to an external server.

I agree that this is a legitimate reason to turn off DoH for yourself (assuming that your customers don't use it themselves, of course).

> I think you're actually just in the much smaller but perfectly legitimate "how to disable" camp, rather than the evil "how to force disable" camp, since you're not trying to keep someone who wants to use DoH from using it.

Yeah not other people's setups (not sure how to do that but it's an interesting question actually, maybe dynamic FW rules trigger by the local resolver's responses?). "How to force disable locally" would probably be the precise term. What I mean by that is network.trr.mode has 5 settings:

- 0: Off by default

- 1: Reserved (previously used for deprecated functionality)

- 2: Secure resolution first

- 3: Secure resolution only

- 4: Reserved (previously used for deprecated functionality)

- 5: Off by choice

and defaults to 0, disabled which may automatically switch to 2 on you in certain circumstances. I switch it to 5 which forces it to stay disabled regardless if Firefox rolls it out automatically in my region or thinks DoH would work correctly in the currently connected network or changes how detection/deployment works in the future.

> Do the domains in question resolve to other IPs on the outside, or do they not resolve at all?

Different, apart from avoiding needing external NAT+FW rules for an internal service my LAN is 10G but my NAT capable router is still only 1G which can surprisingly make a difference pulling files or accessing KVMs and so on through my personal portal.

> If the latter, then Firefox will automatically fall back to local DNS when DoH fails to resolve them. If the former, then I can think of three other solutions that don't require disabling DoH altogether: either switch from split-horizon DNS to NAT reflection, configure Firefox to disable DoH for just that domain and its subdomains, or add IPv6 addresses for them since it doesn't get NATted.

Or just set DoH to force disabled Firefox and avoid rebuilding my network around something that nets me no gain. My external name resolution is already secured, my internal services already work, and I'm already using the most performant path. The only thing I need to set is network.trr.mode to 5 and I'm golden as Firefox .

> If the latter, then Firefox will automatically fall back to local DNS when DoH fails to resolve them.

As stated I've not found the fallback detections to be foolproof. E.g. on top of split-view DNS some organizations point a wildcard record to their landing page meaning any request to the domain always successfully resolves.

Yes, if you're just setting network.trr.mode to 5 on your own systems and not trying to interfere with other people's usage of DoH, there's nothing wrong with that. I'm glad to hear that's all you're doing.

>Indeed. The problem is that a lot of operating systems still don't support it at all yet.

Which one exactly? Android has it called "Private DNS", Linux supports it with systemd-resolved, Windows 10 too (don't know the build number at which it starts). Apple with OS 11 and iOS 14.

The main issue I see is that there is no support for both in every OS. "Private DNS" is DoT, while Windows 10 support is DoH. Apple has both.

DoT is worthless since it's so easy to block at the network level, so I'm not counting Android. And doesn't Windows 10 only support it if you're in the insider program?

Doesn't matter if you count DoT or not. It's still encrypted DNS. You didn't make a distinction in your previous post anyway.

> It's still encrypted DNS.

Does that really matter if censoring connections to the DoT server causes your device to silently fall back to insecure DNS?

Depends on the client. You can construct any viable scenario here, won't matter. Right now you can block DoH too, simply by blocking Cloudflare, Quad9 and Google.

Or we're blocking ads with pihole.

In that case, you can just disable it the normal way on your devices in their end-user settings. That's still not a reason to try to block it at the network level.

Well that's why I want a "how to force disable" guide; to force IPv6 to be disabled on my personal network.

I don't want any device circumventing my private DNS; including IoT devices.

What does this have to do with IPv6?

Also, it's a bad thing if you have a reliable way to block any device on your network from using DoH, because then you'd have a way to block other people's devices from doing so, and so would the rest of the adversaries who want to censor people.

> The automatically rolled out browser specific method described in this article is really directed at users that don't know this is even a choice...

So it's intended to benefit 99.9% of everyday users, then, despite the risk that it might irritate the 0.1% who for whatever reason want things configured some other way. Sounds like they made the right call.

99.9% of "everyday users" don't even know firefox exists, and just use the default browser than came with their OS.

Meh. I run dnsmasq combined with a dns to doh proxy on my router, and I only do that to hide my DNS queries from my ISP, but this is probably paranoia on my part because AT&T ultimately knows the IP of every site I connect to, and I guess I don’t care enough to run a VPN full time. When I do care, I’ve got a droplet running wireguard at my disposal.

> this is probably paranoia on my part because AT&T ultimately knows the IP of every site I connect to

There's a privacy benefit anyway for some sites. If your browser also supports eSNI or ECH, and you're connecting to a site hosted behind a CDN like Cloudflare, your ISP will then only know that you're connecting to the CDN, and not which site behind it that you're visiting.

Firefox socks proxy + ssh is great

I just wish it worked on the whole system

sshuttle does that, with ssh protocol rather than socks.

Ehh, no windows support

You can rub it on WSL2, tell it to listen on 0.0.0.0 and set the WSL2 IP address as the windows’ gateway.

It’s slightly more work, but works quite well for any TCP connection; I’ve actually had 20 windows machines use one Linux machine this was as a poor man’s one way VPN at some point (not recommended to replace a real VPN, but in that case it saved a couple of weeks of calendar time and got the job done)

SOCKS without password authenticatin sadly.

It's not quite as secure as having a password, but you can force the proxy to listen on localhost-only (or any other specific addresss) by specifying it along with the port:

  ssh -D 127.0.0.1:8080 some-host.elsewhere.example

This won't protect you from people who already have access to your host, or from people standing behind you, but at least folks on your network can't use your proxy.

Ref: https://man.openbsd.org/ssh#D

The default is 127.0.0.1, sanely.

Reply on news.ycombinator.com