It is going to be super hard to block DoH since it is indistinguishable from normal HTTPS traffic. If you MITM the HTTPS connection the browser can detect that and refuse to use the connection. Many companies are in this situation that MITMing HTTPS is not working very well. I think Google enforces HSTS[1]. Not sure how that works with DOH. I also think that we need browsers that do not have any other means of DNS resolution than the good old operating system wide /etc/resolv.conf (or similar). I am not going to fight with Google if I have the right to have my own DNS server or not. They are taking the open internet inch by inch. This is the last drop.

1. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

At an enterprise level the browser configuration is controlled by the IT department. Your MITM CA certificate is going to be forced into the trusted list everywhere.

Will that work with websites that pin cert trust anchors?

HPKP is dead for all intents and purposes as far as browsers go. What pinning? The CA certificate store that the browser is using is something any enterprise that is interested in control is already extending by adding their own CA cert - and it has been that way for a very long time.

This approach does break some applications that pin specific certificate instead of relying on "any valid CA" model (e.g. Signal desktop) but that is seen as feature, not a bug, when it comes to enterprise.

>> Your MITM CA certificate is going to be forced into the trusted list everywhere.

Not on my phone.

Then your phone doesn't go on the lan.

OK.

That's a good point -- I wasn't really thinking about the practicability since it's not something I had much interest in. That said, I guess either blackholing the DNS so it can't initially be resolved, or even figuring out any and all IP addresses it resolves to and blackholing those IPs would be a start.

I agree, however, that it should be possible to run your own _______. That's what the internet was meant to be.

Well known public DoH resolvers are going to have well known IPs and will be easy to block.

eSNI and the encrypted TLS handshake proposal that was floated recently rely on fetching keys via DNS, so that's not applicable for DoH, and the handshake for a DoH client will probably be easy to distinguish from an HTTPS client.

It will be easy to block, if you want to.

What if well known DoH resolves are going to be in the same range as the web traffic? If you could distinguish between DoH and HTTPS easily with iptables or pf, sure. I thought it is not that easy.

That really depends on how much Cloudflare and Google are willing to risk.

If enough people block the published DoH resolver IPs, they'll see reduced availability on any hostname that is hosted on the same IPs; but if Cloudflare and Google put important content on the same IPs, it makes it harder to block.

Enterprise networks should generally be forcing all HTTPS traffic through proxies.

This requires local client certificates to be installed.

This works great when you have all of your computers in an office, like in 1999.

This still works if you use a VPN correctly.