Hacker News Reader

Comment by fiddlerwoaroof | Hacker News Reader

How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.

View on HN

If the network allows outbound traffic, they can hard-code an IP list - this is how Cloudflare’s 1.1.1.1 works and malware has done this for decades – or they can use local DNS to resolve a single name which will answer or redirect to a service which does further queries. Malware commonly used IRC for this until that started getting blocked on most networks, but imagine how easy it would be to miss, say, a bot which connects on 443 to a major hosting provider, like half the apps you run, searches Google.com, Twitter, etc., or hits an ad network for a keyword selected by the attacker.

In every case, once they get the server(s) to connect to you lose all further visibility unless you’re blocking 443 and forcing traffic through an inspection proxy.

Yeah, it’s an arms race, but I suspect it’s solvable: at least solvable enough that it’s feasible to just not use devices that break your policies. For things like Pi-Hole, the setup I describe will reduce much of the ad noise even without more complicated systems.

The way to solve is either to segregate unmanaged devices onto a separate network and give up on controlling them or to implement the system I described. The same Pi running a DNS server can run a proxy which applies blocking policies on all hostnames.

> The same Pi running a DNS server can run a proxy which applies blocking policies on all hostnames.

With DoH, it's easy to not just hardcode the resolver's IP but also the resolver's certificate. How would a proxy be able to intercept that?

If you configure an HTTPS proxy, the client will use the proxy's name to verify the connection to the proxy and trust that the proxy will verify the remote connection.

If you're trying to configure transparent proxying where the network redirects traffic to a different device, you would need to have a local CA so you can forge certificates — that's not uncommon in enterprise IT but it's definitely a security risk associated to having something which can MITM anything on your network.

In either case, the real question is whether you control the endpoint. If it doesn't support configuring a proxy or installing a CA, all you have is the binary decision to decide whether or not to allow it on the network at all since whoever does control the client has so many options for smuggling traffic out.

> If the network allows outbound traffic, they can hard-code an IP list - this is how Cloudflare’s 1.1.1.1 works and malware has done this for decades – or they can use local DNS to resolve a single name

Why can't you redirect all 53 traffic to a pihole and block that single name?

In this case the client isn't sending traffic on port 53 at all — they already have the IP for the target server and so they just open a connection to it on port 443.

This is not hypothetical: it's how DoH works now but it's also how various things have worked for decades. Malware liked it for hiding command-and-control name queries from the few people who monitor DNS but it was also an option for anyone who had problems with buggy or malicious local DNS servers to add public resolvers like 8.8.8.8 or their own infrastructure into the search list so they didn't get support calls due to some ISP breaking their own DNS server.

The key part is remembering that this was always possible. DoH just meant that more people became aware of the gap they'd always had in their network management.

Based on this: https://stackoverflow.com/questions/33099569/how-does-sock-5...

> Firefox, for example, sends hostname to SOCKS proxy without resolving it.

So a simple proxy can bypass local restrictions.

-----

I remember doing something similar back in my IT days just to see if it was possible. It was.

> If the router is redirecting all port 53 traffic

Then it won't do anything to DNS over HTTPS traffic that is going over port 443. And it won't be able to distinguish that traffic from any other HTTPS traffic.

There’s theoretically ways to solve that: https://news.ycombinator.com/item?id=25349358

How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? What about 80 or 443?

> How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? How about 80 or 443?

Just because it is not a silver bullet doesn't mean it is not effective for a large percentage of users.

Well, it’s more complicated, but in theory you could do some deep packet inspection that understands the protocols: personally, I’d use this to break DoH connections (for every host name seen in SNI, attempt a DoH query, if it resolves, reset the connection) and attempt to force everything to fall back to plain DNS. Then, whitelist a couple outbound ports (on most networks, maybe just 443 + 53?) and block VPNs.

> or every host name seen in SNI

Not going to be possible in a few years or so:

https://news.ycombinator.com/item?id=25344311

meh. The outer SNI and the IP address still tell a lot about what you are doing online.

Also, with things like this, you can just reset connections using HTTPS features you don’t support. It might eventually become painful, but it’ll be fine for the near future. And, if enough enterprise middleboxes do this, the standards will be DOA.

With the Portmaster (https://github.com/safing/portmaster) we're going in that direction, but it will take a couple more years to be able to go that deep. Have a look!

https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

Reply on news.ycombinator.com