Well I hadn't really thought too much about DoH until now but now I've gone and enabled it on a few machines.
While I don't love all the snark in the article I'm glad this was brought to my attention. Hopefully this raises enough awareness that it has the exact opposite effect of what the ISPA in the UK hoped for.
Exactly. If I was them I'd claim that was precisely the objective - any press is good press. Labeling them a villain temporarily did more for Mozilla/DoH than labeling them the ultimate good guy would have.
The snark is on par for the course for most articles from that site, which can be expected when publishing under the slogan 'Biting the hand that feeds IT'
I love how their actual retraction, (https://www.ispa.org.uk/ispa-withdraws-mozilla-internet-vill...) includes a list of what "Any implementation of DoH [...] should be capable of achieving [in terms of] the expected privacy and security benefits" and then basically just lists everything Mozilla already champions.
If you are going to do this approach, make sure that your ISP's router/modem is not on the same network. I.e. you should be running your own network, then have it connect to the outside world through the Pi-hole which is the only device that is connected to the ISP-controlled hardware.
Otherwise, their hardware could just be reading everything and reporting home on it, since it'd be able to see the unencrypted DNS requests that are sent over its network to the Pi-hole.
So when Firefox demands DoH for good and all, it won't work with a PiHole because it will demand to only talk to Cloudflare's DNS and the PiHole won't be able to MITM it?
From ISPA's website, one of the reasons to oppose DoH:
> User choice: An application switching to DoH should ensure that this switch does not undermine choices that have been previously made by the user. For example, if parents have decided to filter an internet connection in their home via network or local level DNS controls, these choices should not simply be ignored by the application.
If a parent is capable of filtering out internet traffic at DNS level, then they should be capable of doing the same on top of DoH.
Then, after some more vague concerns and handwaving, at the very end we have:
> User and access-network-operator support: If DoH doesn’t work or is slow, a customer’s internet access will be affected. The customer will contact their ISP, not the DoH provider, but the ISP won’t be able to fix things for them. As a minimum, any application switching to DoH should ensure that the selected resolver should provide a 24/7 user call centre reachable via low-cost/local rate telephony and an online support capability. Support for fault-diagnosis and resolution between ISP, resolver and users should also be provided.
I mean, I get that if a person is unaware of a custom DNS that some application is using they might fault ISPs for network failures due to DNS trouble, but this would happen with any DNS irrespective of DoH.
> If a parent is capable of filtering out internet traffic at DNS level, then they should be capable of doing the same on top of DoH.
Home filtering solutions using DNS either tend to rely on being the DNS server, or upstream filtering (e.g. the filtering ISPs provide where the parent gets a web interface with their subscription). In either situation they're sold to parents as easy to use solutions, not as things they build and install and understand underneath.
That kind of filtering over DoH can be harder because there's plenty of edge cases when DoH is thrown into the mix that complicate things massively.
It's also worth bearing in mind that swapping DNS interception at the ISP for DNS interception at Cloudflare can be more displacement than improvement (where the ISP isn't screwing with people's connections, for example).
Finally, what's being talked about with DoH is going to be baked into browsers, not into the OS. This is the biggest support headache for ISPs and probably the source of that support argument. It's understandable to be concerned about variants of "My Apple mail is working but I can't see Facebook" support calls.
Sure, ISPA are utterly tone deaf and deserve to be shot down for targeting Firefox this way, but DoH isn't the panacea some people are making it out to be and there will be lots of edge cases dropping out if browsers start ignoring OS settings and doing their own things.
> For example, if you configure your system to use Cloudflare's DoH service and visit a Cloudflare-hosted site over HTTPS, such as El Reg, your ISP will only see outbound connections to Cloudflare and have no idea what exactly you're leafing through: in this case, The Reg.
Doesn't the "HOST" field of the HTTPS negotiation give this data away to the ISP anyways?
If you use ESNI (that encrypts SNI field in SSL handshake) and the server uses ESNI, and you both use TLS 1.3 (that encrypts server certificate) then it is difficult to determine domain name. Latest Firefox supports both of there features, as well as DoH.
In case anybody is interested, you can visit https://www.cloudflare.com/ssl/encrypted-sni/ to see whether you have all features that prevent leaking the domain names that you visit. In Firefox 67 with network.security.esni.enabled set to true, all tests are passed.
36 comments
[ 3.0 ms ] story [ 81.7 ms ] threadWhile I don't love all the snark in the article I'm glad this was brought to my attention. Hopefully this raises enough awareness that it has the exact opposite effect of what the ISPA in the UK hoped for.
https://news.ycombinator.com/item?id=20371741
Also, we still have the problem with the unencrypted SNI after the name is resolved.
This is what I had to do to enable DoH through Firefox preferences:
- Click the hamburger icon
- Go to preferences
- Scroll down to network settings and click settings
- Click "Enable DNS over HTTPS"
(By default, this uses Cloudflare as your DNS server, but that can be further configured if you want)
It just makes the whole thing even more sad.
Hadn't realized FF had shipped support for it already.
https://docs.pi-hole.net/guides/dns-over-https/
This would essentially enable DoH on all the computers that use the pihole as DNS, assuming you're not worried about people snooping on your own LAN.
Otherwise, their hardware could just be reading everything and reporting home on it, since it'd be able to see the unencrypted DNS requests that are sent over its network to the Pi-hole.
> User choice: An application switching to DoH should ensure that this switch does not undermine choices that have been previously made by the user. For example, if parents have decided to filter an internet connection in their home via network or local level DNS controls, these choices should not simply be ignored by the application.
If a parent is capable of filtering out internet traffic at DNS level, then they should be capable of doing the same on top of DoH.
Then, after some more vague concerns and handwaving, at the very end we have:
> User and access-network-operator support: If DoH doesn’t work or is slow, a customer’s internet access will be affected. The customer will contact their ISP, not the DoH provider, but the ISP won’t be able to fix things for them. As a minimum, any application switching to DoH should ensure that the selected resolver should provide a 24/7 user call centre reachable via low-cost/local rate telephony and an online support capability. Support for fault-diagnosis and resolution between ISP, resolver and users should also be provided.
I mean, I get that if a person is unaware of a custom DNS that some application is using they might fault ISPs for network failures due to DNS trouble, but this would happen with any DNS irrespective of DoH.
Home filtering solutions using DNS either tend to rely on being the DNS server, or upstream filtering (e.g. the filtering ISPs provide where the parent gets a web interface with their subscription). In either situation they're sold to parents as easy to use solutions, not as things they build and install and understand underneath.
That kind of filtering over DoH can be harder because there's plenty of edge cases when DoH is thrown into the mix that complicate things massively.
It's also worth bearing in mind that swapping DNS interception at the ISP for DNS interception at Cloudflare can be more displacement than improvement (where the ISP isn't screwing with people's connections, for example).
Finally, what's being talked about with DoH is going to be baked into browsers, not into the OS. This is the biggest support headache for ISPs and probably the source of that support argument. It's understandable to be concerned about variants of "My Apple mail is working but I can't see Facebook" support calls.
Sure, ISPA are utterly tone deaf and deserve to be shot down for targeting Firefox this way, but DoH isn't the panacea some people are making it out to be and there will be lots of edge cases dropping out if browsers start ignoring OS settings and doing their own things.
Doesn't the "HOST" field of the HTTPS negotiation give this data away to the ISP anyways?