Comment by throw0101a | Hacker News Reader

Comment by throw0101a | Hacker News Reader

Parent Full thread

> No. Run your own DoH server, point your DoH client to your own DoH server ...

Except when the client ignores what you tell it. Per Paul Vixie:

   google, this is bogus as hell. my dhcp server gives you dns servers to 
   use. please don't make me route and answer 8.8.8.8 just to watch youtube.
   
   > [71] 2019-02-13 16:39:40.548137 [#68 vtnet0 4095] \
   >         [24.104.150.186].56915 [8.8.8.8].53  \
   >         dns QUERY,NOERROR,7357,rd \
   >         1 lh3.googleusercontent.com,IN,A 0 0 0
   > [71] 2019-02-13 16:39:40.548210 [#69 vtnet0 4095] \
   >         [24.104.150.186].56915 [8.8.8.8].53  \
   >         dns QUERY,NOERROR,49247,rd \
   >         1 lh3.googleusercontent.com,IN,AAAA 0 0 0
   
   (no, this device i've paid for, will NOT be allowed to send you any 
   information, other than what i personally approve, which will never 
   include DNS traffic. if you don't like that deal, buy it back from me 
   and i'll find some other video appliance that doesn't twist my arm.)

* https://news.ycombinator.com/item?id=19170671

Of course with DoH you can't just do a UDP redirect. With DoT, which uses tcp/953, you can at least block access.

But with DoH, you have just lost control of your network. (Unless block 443 and force everything to go through a (Squid) proxy?)

Paul Vixie isn't making any sense here either.

If you can't trust your device, you can't trust it without DoH either. As I said upthread, devices don't even need to use DNS. They can open up encrypted C&C channels, using whatever protocol they'd like, tunneled over whatever they'd like. They can bake rendezvous IP addresses in, they can cryptographically verify endpoints to break MITM proxies, they can even sneak data out in ICMP packets. DoH has literally nothing to do with it.

What's insidious about this argument is that it preys on peoples legitimate concerns about uncontrolled devices on their network. We're all concerned about that! But that doesn't mean we should use plaintext DNS, or Paul Vixie's preferred "encrypted DNS with a killswitch for network operators".

Fighting against an HTTPS endpoint on 443 returning data in response to a query is kinda futile.

Might as well argue against using windmills to grind wheat.

I mean, the actual solution here is... don't buy devices that refuse to do what you tell them. Don't use closed-source, auto-updating software. You can live without a Chromecast and a Amazon Echo and your cloud-based smart lighting system. There's alternatives to all these things anyway, which do what you tell them to.

> Don't use closed-source, auto-updating software.

Sometimes you don't choose the software, the software chooses you:

* https://www.zdnet.com/article/first-ever-malware-strain-spot...

* https://www.zdnet.com/article/psixbot-malware-upgraded-with-...

Malware can do whatever it wants anyway - DNS-over-whatever can be implemented no matter who supports it. Maybe we should be banning Tor because it might be used by malware?

Tor has its own traffic signature and so can be detected by network monitoring software. If it's on the IT network I help run then I'm tracking down the source IP and MAC and finding the network port it's coming from and asking "WTF?".

I'm happy to implement DoT on work's network to help encourage encrypted DNS. My problem is DoH can now be used by all sorts garbage and we can't tell it from legitimate HTTPS--which is by design.

All this for the laudable goal of protecting Internet surfers' privacy. However I'm curious to know how well this will work against the Great Firewall of China, and how many other regimes will now implement Great Firewalls of their own.

Tor has bridges, which are specifically designed to thwart the Great Firewall - and I'm guessing your network monitoring software.

Malware can ship with an arbitrary number of DNS-over-HTTPS servers accessible anyway, no matter whether Google supports it. The cat was out of the bag as soon as you allowed encryption on your network in general.

Finally, there are system architectures that are inherently less susceptible to malware, which is what we should really be focusing on. If your document viewer doesn't need to access the Internet, why does it have access to the Internet? Why does your general-web-browsing browser have access to your intranet and worse, your network drives and USB sticks? The reason we're stuck with what we have now is that operating systems research largely died in the 90s, but we're now aware that e.g. microkernel capability systems can be implemented in ways that are both fast and secure.

Tor also gives you the option to use a variety of pluggable transports, which are purpose-built to circumvent DPI boxes and such. Pretty sure obfs4 (based on [1]) works against the GFW.

[1] https://www.cs.kau.se/philwint/scramblesuit/wpes2013.pdf

> But with DoH, you have just lost control of your network. (Unless block 443 and force everything to go through a (Squid) proxy?)

Expect “enterprise” network equipment using an approach like this to provide a “DOH firewall” in the near future.

Net privacy gained: negative.

I've been on networks where everything had to go through a proxy, where browsers were told how to act via WPAD/proxy.pac and you set an HTTPS_PROXY env for wget/cURL to work.

The goal isn’t adding privacy on enterprise networks. Enterprise networks should already be accounting for the existence of HTTPS, and either allowing, blocking, or proxying employee/device connections based on their threat model.

The goal for DoH is to improve privacy for individual humans, and it does that.

Reply on news.ycombinator.com