Hacker News Reader

Comment by acdha | Hacker News Reader

> At this point Mozilla is just the Non-profit Arm of Google, They do what google tells them

You can just say you don’t follow this closely. Mozilla is not perfect but they do push for privacy, with an increasingly limited amount of negotiating power.

> DoH is absolutely designed to get around network based security and filtering, both for Ad's and other reasons.

This is similarly reflecting a poor understanding of the situation. DoH can’t get around network filtering - if you block packets, there’s no magic trick to bypass it. It’s great for preventing ISPs from tampering with traffic or monitoring activity (this will also require eSNI to complete) but it’s not giving an attacker any capability they didn’t already have. If you’re concerned about security you’re fooling yourself if you don’t have endpoint management and some level of network segmentation and egress control. Attackers have hard-coded DNS servers, C&C endpoints, etc. for decades.

View on HN

Your technical description doesn't really respond to the meat of the critique of DoH, which is that it prevents the technique described in this article - transparent proxying for all traffic of a certain service, in this case DNS.

The problem is that your relationship with your network devices is logically the same as a totalitarian country's/company's relationship with their citizens/users. So any protocol that prevents censorship/surveillance by ISPs also impinges upon bona fide network administrators. Corporate networks have the same dynamic, although there are few tears shed when it becomes harder for them to tamper with users' traffic.

The right answer is to make sure devices that have any Internet access run code you control. The root of the problem here is buying a "smart" TV, hooking it up to the network, and then expecting to tame all of its user-hostile anti-features by policing its communication. The only way to use black box IoT devices is to remove all general Internet access from them, allowing communication only with hosts you do control. For instance I've got a network of tp-link bulbs that are all controlled from a Home Assistant instance, and they never have and never will get a packet out to the larger Internet.

My point was simply that DNS was never an effective measure. Corporate operators don’t need it since they can configure proxies and install endpoint monitoring, but the people building untrustworthy IoT devices or malware can’t be relied upon to cooperate.

I agree that the core problem here is blocking egress entirely – and that’d be a good area for home routers to add UI polish so you could easily allow your TV to hit Samsung.com if there’s an update you need before turning it back off. Unfortunately that’s going to be a losing game for many devices and that really hits at the root cause: we need strong regulation controlling privacy because trying to stop a well-funded company with purely technical measures is almost always a losing game.

Well DNS has been a pragmatic measure for quite some time. I've definitely seen jailbreaks of embedded devices that start off by MITMing DNS to proxy all traffic. DoH is changing that, and I can see how that's annoying.

> hit Samsung.com if there’s an update you need

Why would you need an update? Updates are mainly necessary for security, which you don't need if the device isn't on the Internet. If the device doesn't have all the features you expect out of the box, return it within the return period. There's a small corner case where an update could carry significantly increased functionality, but it seems easier to ad-hoc address that down the line rather than plan for it. Carelessly doing updates is a good way to break your device.

> Unfortunately that’s going to be a losing game for many devices

I don't see how it's a losing game if you play it correctly. Fine grained policing of types of traffic is a losing game, but wholesale denying transit isn't. There is little difference between my network of tp-link bulbs and a local modbus network.

> Why would you need an update? Updates are mainly necessary for security, which you don't need if the device isn't on the Internet.

You've never had a problem which was fixed by an update or something which added support for, say, a new model peripheral? I have, which is why I allowed for the possibility of wanting to do this on the schedule of your choosing but not the default case.

> I don't see how it's a losing game if you play it correctly. Fine grained policing of types of traffic is a losing game, but wholesale denying transit isn't. There is little difference between my network of tp-link bulbs and say a local modbus network.

I was thinking less narrowly than devices which never need to be online. A TV connected to other players can run entirely offline but there are many other things which legitimately need connectivity and there's no good way to prevent that. For example, think about a device like a Chromecast or Fire TV, or those Facebook video chat appliances — people buy those to stream content so the most you can do is force the vendor to send marketing stuff through the same endpoint they use for your content, and that's increasingly hard to filter (think how useful a “it goes to an IP in AWS. Block y/n?” prompt is). That's why I said it'll require a legal fix since a large fraction of the most invasive devices either already do or could trivially be modified to mix other data in with the traffic needed to function.

> You've never had a problem which was fixed by an update or something which added support for, say, a new model peripheral

For embedded devices? No. I can imagine it happening in general, but I don't think I would ever buy into a proprietary ecosystem so hard that there would be peripherals, and newly released ones at that. Still I would be cautious about doing said updates, lest they ruin the device I already have. Like I've got a newer Marantz receiver that works great and hasn't seen the Internet in several years. Even if they developed some new desirable feature, why would I want to let it reflash itself and possibly break, or even just get slower (software bloat)? I'd rather just continue using it as I bought it.

> there are many other things which legitimately need connectivity and there's no good way to prevent that

I sort things into categories. A TV would be in the category of "wtf would you ever hook that up online" - Internet access can only enable anti-features. A Chromecast is a different category - single purpose disposable device that if it turns into shit you just throw it out. Ads and surveillance are part of its price, and if your goal is to avoid them, you should just setup a Kodi box and call it a day.

Legally I don't really see what you're getting at here. I can see a law for my TV category, but leaving it disconnected or pulling the 5G modem will also solve that. How would you even begin to solve the Chromecast problem with a law? Maybe in the EU you could convince them to mandate unbundling ads from a service, but in the US exploiting consumers by shoving ads at them is one of the most popular business models. I don't see that ever changing via the legal system.

DoH absolutely can get network filtering: if I block port 53 outbound to control DNS queries within my network, DoH (and other tunneling technologies) is bypassing my network filtering of DNS.

By the same logic HTTPS is bypassing your network filtering of every service which happens to have an alternative available over HTTPS. So do you block HTTPS?

I’ve been thinking about installing a proxy with my own root for this reason.

I would not want to use your network if that was the case, and I wonder if you similarly would use someone else's network if it was configured like that. I don't think network operators who provide access to the Internet can realistically expect to control what their users do on the Internet, unless the network operator is also the administrator of those workstations.

Maybe, but my rule is: my home network, my rules. I can’t really do this invisibly anyways: any device I don’t control will get certificate validation errors.

The problem here is even the device owner is not the "administrator" of the device as we have lost ownership rights, locked behind EULA's, Patents and copyright

The point of the original story is "your" meaning a device you own, is ignoring your network controls

it is highly unlikely that the TV manufacturer is going to allow me to install my own custom root certs to inspect their traffic to HTTPS, so yes DoH and other things are a threat to network security, because if the TV become compromised I have limited administrative controls to prevent it other the blocking it completely which is a poor response to the problem

DoH is a solution in search of a problem that can be solves in better more user friendly ways

They could do that any time without DoH, as has been done for years. Your true choice is allowing network access or not.

Yes, from your IoT devices maybe you do.

The usual approach to setting up a firewall is a default of "block everything" and then selectively allow only what is needed.

Most people cheat and only do this on inbound connections, allowing everything on the egress side, because it's easier. But if you want to block your IoT devices from making outbound https connections, you easily can.

There's nothing really new going on here. It's always been possible to tunnel one protocol over another, or use nonstandard ports, and use encryption on the traffic to hide what you're doing.

I would absolutely love to have control over HTTPS traffic on my network, specifically to enable my Squid proxy to cache HTTPS pages, but unfortunately not every device or even program supports custom CA's. I'd be the man-in-the-middle between the internet and every device I own.

I think that is a pretty user-hostile attitude and I suspect you probably wouldn't really love it if every network operator was doing that kind of thing.

What’s user-hostile is every consumer device insisting on pushing its defaults and ignoring any network policies I’ve configured.

Yes, I agree that is also user-hostile, since it should be configurable. The problem is not about network policies though, since DHCP is explicitly not designed to be a policy and is purposely meant to be optional for the client.

For this reason I wouldn't recommend buying a device like the Chromecast, in which the user can't configure the network settings. Instead maybe consider something like the Amazon Fire Stick which is not as user-hostile.

I read that as LanternLight83 is both the network operator and the user in this case, and if so it’s not really a problem.

I would also love to MitM myself in some cases, mostly because it’d be interesting to see what’s going on.

Yes, but my point is that if you feel it's justified for your own network then you ought to expect every other network operator will feel that way about their network too.

So before applying that mentality, it would be wise to consider what your experience would be like if all your neighbours, friends, colleagues etc also did that on their networks.

I have no problem with that: if my workplace MITMs traffic, I’ll use my cellphone connection and a personal laptop for sensitive data. If a friend’s house mitms traffic, same deal.

Is the point that I sometimes use these networks? Then I somewhat agree - I would set up a separate guest network without shenanigans for guests to use. This avoids both the ethical sketchiness and having to explain why their web browser is shouting at them

True, that could be a good compromise. Although there are still some disadvantages like creating an SPoF for yourself and increasing your attack surface (e.g. anyone who compromises your internal CA has access to all your encrypted connections)

You don’t need to MitM. Squid can use SNI to allow whitelisted hosts, for now at least.

Hopefully that will be fixed with widespread usage of TLS ESNI/ECH

Network filtering means blocking traffic at the network level. Trying to use DNS for this leaves you trusting the client - and there are decades of precedent for clients bypassing that for various reasons, such as this post shows.

The solution is to start doing network filtering: if you block packets to unapproved servers, you can actually stop this. You’ll need to run your own proxy, of course, but that’s always been the only way to actually accomplish that goal.

That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy.

You’ll note that I mentioned a proxy. That’s why: you need to force all traffic through a proxy you control or you’re just hoping that a client doesn’t use hard-coded IPs or an outside API of some source. If your network allows the client to send traffic to port 443 anywhere, any blocking is on the honor system.

My question here is how are you going to install your root certificate on a $300 smart TV? Or, if that is not required because the TV does not verify DoH certificates, how bad is that for security (which we already know is awful on these devices)?

Well, it’d just block internet access there. I wonder if it’s possible to push a root to an Apple TV

The Checkrain jailbreak [0] supports several Apple TVs, so I’d bet you could use use certbot to obtain a LetEncrypt [1] cert for it.

Of course, jailbreaking opens up other security issues, so it goes back to what you can tolerate.

[0] https://checkrain.org/ [1] https://letsencrypt.org/getting-started/

I know that you can install iOS profiles onto the Apple TV, I have done this for 802.1x support, which included a CA root for the 802.1x controller.

I would imagine you can use this to push any certificate that you can also push to an iOS/iPadOS/macOS device.

This is what I was thinking about.

This comes back to the core decision: do you care about controlling the network enough to block access? If the device can't be managed / is no longer supported the safest choice is not to allow it online at all. Different people will have different risk tolerances – it might make sense to put, say, a remote-control power switch on an IoT no-man's land network but if it has access to personal information or cameras/microphones it's not unreasonable to say it should just be blocked unless you're actively using those features.

"That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy."

This is a very good point and I am dealing with this myself on my home networks.

Like any household/family we have some number of dubious/untrusted devices that still need Internet access.

By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.

DoH breaks all of this.

I have no interest in diving down the "MITM my own network by inserting custom certs into embedded devices that may or may not use them".

Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP connected to, outbound, from your network - and then block all IPs that answer your DoH query. You're basically pre-testing all new SSL connections to see if they are to a DoH resolver that you (presumably) don't want to talk to ...

This solves the CDN problem ... does it solve the problem entirely ? I have only just thought of this moments ago ...

> By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.

This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective.

> Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP that initiates a new connection, outbound, from your network - and then block all IPs that answer your DoH query.

It doesn't solve the CDN problem: CDNs will route traffic based on the hostname and blocking them will have a degree of collateral damage which most people can't work with. Setting up your own HTTPS proxy avoids this.

"This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective."

If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers.

That kind of control is what DoH breaks and I'd love to find an elegant (non-MITM proxy) solution for it ...

There isn’t an effective solution for a device which ignores local network policy other than returning it so the manufacturer pays the cost of designing a bad system.

With the side effect of your local vendor refusing to do further business with you, "the problem customer", with your "unreasonable demands" and technobable.

I use iptables on an openwrt router to redirect all traffic on port 53 to my own DNS

DNS over HTTPS has been a thing since before IETF standardized it, the technique was just in the form of a non-standardized API running on some benign domain.

Thinking about it, if you’re willing to give up TLS 1.3, you could probably just break all https connections with encrypted SNI and then filter based on the SNI information.

Just to nitpick: TLS 1.3 still uses plaintext SNI by default. You need to explicitly put public keys in DNS to enable the encrypted SNI extension.

And in the context of pihole and such, avoiding that means editing the DNS response to remove those public keys. Which takes us full circle back to "do I control DNS for this gadget, or not".

Well, it’s easy to control the DNS if you can block DoH and VPNs: just have your router forward all traffic on port 53 to a resolver you control.

Right now you can block the common IPs for the DoH servers and be fine.

So I need to mitm https traffic for devices I can't change the ssl trust store on?

You have two choices: trust the device or don’t let it on the network. Voluntary measures like local DNS only work to the extent that the device maker wants them to.

The issue isn't network filtering, it's encryption.

Standard DNS is unencrypted. DNS-over-HTTP is encrypted. Or DNSSEC or any number of newer standards that secure the DNS lookup. At that point, filtering will require MITM proxies, whether it's for DNS or HTTP or any other protocol.

It's a trade-off with security on the open network meaning harder penetration and control in your internal network. There's no easy answer.

DNSSEC is not encrypted. Moreover, between end systems and DNS servers --- the scenario we're discussing on this thread --- it isn't even authenticated.

Sure, DNSSEC provides authentication and integrity rather than encrypted traffic, which makes spoofing or rewriting the responses hard.

Why do you say it's not authenticated? If they're using the newer standards then that's what it provides. If they're not then there's no issue with network filtering as usual.

Again: the article discusses an environment where machines on a home network are refusing to use the DNS servers the network is configured to use. DNSSEC authenticates requests between servers. But between DNS clients ("stub resolvers") and servers ("full recursers"), there is no authentication, just a single bit in the header that says "trust me, I authenticated this data".

It doesn't matter if you're using your ISP's servers, 8.8.8.8, 1.1.1.1, or a custom server you set up on Digital Ocean somewhere: an on-path attacker can forge DNSSEC responses to you. It's a ridiculous situation.

Denial is not just a river in Egypt

Follow the money .. watch the actions not the words

You mean actions like the Mozilla engineers advocating for users in standards groups or industry coordinating teams? Or the ones building privacy-oriented features?

You’re going to have to make a more substantial argument to get anywhere with this.

Reply on news.ycombinator.com