4 ms·
So the solution could be to make it so that there are many DoH providers and a browser would choose one of them randomly (or by user's choice).
by codedokode 7y ago
So the solution could be to make it so that there are many DoH providers and a browser would choose one of them randomly (or by user's choice).
- brians 7y agoTor has some nice papers about what happens if you try that: the NSA and KGB each run a server and content themselves with getting a sample of the population.
- southerntofu 7y ago> the NSA and KGB each run a server and content themselves with getting a sample Which is already a lot better than getting 100% from simply spying on CloudFlare or serving them with "National Security Letters".
- dreamcompiler 7y agoOr -- much better -- use DoT instead of DoH so port 443 isn't getting misused for DNS.
- tastroder 7y agoWhile that's an unpopular opinion I tend to agree, I'm still on the fence if that's really bad or if I'm just grumpy about change though. It really feels like instead of fixing the underlying problems we're duct taping the internet by moving HTTPS to OSI layer 4 and making TCP and the concept of ports obsolete for a majority of use cases - which in many cases implies a loss of control. I'm honestly not sure why our sector pushes HTTPS solutions over plain TLS, is it just because it blends in with web traffic and it's easier to grasp because more people are familiar with the basic concepts? Of course there's arguments for and against these aspects in the case of name resolution, both technical and on a legislative level, but maybe a net win in terms of privacy protection for the majority of users is still worth it. And should Cloudflare or whoever decide to misbehave with the data we send, it'll at least be easy to switch to other providers when DoH is widely adopted.
- cameronbrown 7y agoYou're right of course, but HTTP(S) only 'won' because of the web.
- berti 7y agoThat would break the internet for many innocent souls behind firewalls.
- dngray 7y ago> Or -- much better -- use DoT instead of DoH so port 443 isn't getting misused for DNS. DNS over TLS has other issues. There's a nice comparison there https://dnscrypt.info/faq/ https://dnscrypt.info/faq/ I have been using local resolver on 53, that forwards all requests from my LAN into DNSCrypt (and sends that over a VPN tunnel). That way I maintain privacy, and decentralization as well as being able to simply use the DNS resolver built into my OS. I have to wonder though with HTTP/3 https://en.wikipedia.org/wiki/HTTP/3 https://en.wikipedia.org/wiki/HTTP/3 being QUIC based, will we see DNS over QUIC? https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC Seems like Firefox doesn't even support QUIC at the moment. https://bugzilla.mozilla.org/show_bug.cgi?id=1158011 https://bugzilla.mozilla.org/show_bug.cgi?id=1158011
- tialaramex 7y agoThe IETF QUIC isn't finished. Periodically the Working Group thinks it has stopped fiddling with the low-level bit layout and is ready to focus on polish, then somebody finds a show stopper that means revisiting the low-level bits. Maybe 2020? They missed all their advisory target dates (July 2019) for actually writing documents, and that isn't the end by any means for a protocol like this. So Firefox could at most support either Google QUIC (internal prototype, now obsolete, who cares?) or a random draft that may end up not resembling the final product. If they haven't decided to do either it doesn't seem like a big deal.
- dngray 7y ago> The IETF QUIC isn't finished. Periodically the Working Group thinks it has stopped fiddling with the low-level bit layout and is ready to focus on polish, then somebody finds a show stopper that means revisiting the low-level bits. Maybe 2020? Ah yes you're right. Also Mozilla (M. Thomson, Ed) is on the author list there so I expect they will support it when it is finalized. https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ Hopefully then they also support DNS over QUIC, I expect they probably will once QUIC is finalized. I think DoH is just a stop-gap measure to be honest. https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/ https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic...
- codedokode 7y agoThen it would be easier for an ISP to block encrypted DNS (by port number). It is better to masquerade everything as normal HTTPS to make blocking more difficult.
- ti_ranger 7y ago> Then it would be easier for an ISP to block encrypted DNS (by port number). It is better to masquerade everything as normal HTTPS to make blocking more difficult. For most people, if you can't trust your ISP, you have bigger problems. For people who can trust their ISP, why should we all by default be affected by the fact that the Mozilla developers seem to all live in a non-free or non-democratic country. Maybe they should instead focus on fixing the US political system that results in their current situation, rather than trying to use technical means to solve political problems.
- darkwater 7y agoWhat if you can trust your ISP most of the times but not during a specific time? For example, when there are civilian protests/acts which the current government doesn't like? I have a very specific case for this: in the days before and during the referendum for the Catalonia independence (Oct 1s 2017), all the spanish ISPs where blocking access to the websites related with the referendum, using DPI to look for the SNI hostname. One of the main reasons to enable DoH in FF is to enable the encrypted SNI feature https://miketabor.com/enable-dns-over-https-and-encrypted-sni-in-firefox/ https://miketabor.com/enable-dns-over-https-and-encrypted-sn...