6 ms·
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
by StreamBright 6y ago
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 https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
- rasengan 6y agoThat'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.
- XorNot 6y agoAt 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.
- kortilla 6y agoWill that work with websites that pin cert trust anchors?
- vaduz 6y agoHPKP 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.
- phkahler 6y ago>> Your MITM CA certificate is going to be forced into the trusted list everywhere. Not on my phone.
- pstrateman 6y agoThen your phone doesn't go on the lan.
- phkahler 6y agoOK.
- toast0 6y agoWell 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.
- StreamBright 6y agoWhat 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.
- toast0 6y agoThat 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.
- pstrateman 6y agoEnterprise networks should generally be forcing all HTTPS traffic through proxies. This requires local client certificates to be installed.
- sneak 6y agoThis works great when you have all of your computers in an office, like in 1999.
- pstrateman 6y agoThis still works if you use a VPN correctly.