Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside Firefox’s DNS-over-HTTPS engine

daniel.haxx.se

Post reply on HN
Print view View original

91–100 of 134 posts

Re: Inside Firefox’s DNS-over-HTTPS engine

#91

Post by sp332 »

j0057 wrote: post #84

I'm not very happy we're now going to send all DNS traffic to 6 centralized DNS-over-HTTPS servers[1]. We can't trust our ISP, but we can trust Google and Cloudflare? I also noticed that when I configure my Android's proxy settings to point at a Privoxy container that routes through a VPN, I still get DNS-hijacked to my provider's "thepiratebay.org has been blocked for you" page -- this only happens in Chrome mobile,…

Mozilla actually has a contract with CloudFlare to protect user data. It's stricter than CF's normal privacy policy which applies to other users of the DNS-over-HTTPS service. Only 3 types of aggregate information will be kept for more than 24 hours. https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...

Re: Inside Firefox’s DNS-over-HTTPS engine

#92

Post by geofft »

watermelon0 wrote: post #44
greglindahl wrote: post #28

Earlier quoted context omitted.

You might have noticed that Firefox runs in a lot of messed up environments, where, for example, bad installers downloaded by the user have done many bad things to the OS, including installing bogus hosts files which block known anti-virus and anti-malware websites. Firefox had a huge crackdown on malicious toolbars and extensions, and that was a good thing for most people. Do you have a clever suggestion for how Fir…

If malware can modify /etc/hosts, then it shouldn't have any problems modifying Firefox executable or, even easier, it's configuration.

This is true, but most malware is neither high-effort nor high-quality. It's very easy to edit /etc/hosts. It's a lot harder to inject yourself into the binary in a way that works. It's harder still to inject yourself into the binary in a way that works if the binary is actively trying to not be injected into, or using some security-by-obscurity scheme for signing the config, or whatever. Yes, it's all running at the same privilege level (or lower) and the malware technically has the access, but it's not cost-effective to have battle-hardened automatic reverse-engineering tech built into your malware.

Chrome in particular has a DLL blacklist that seems to work very well in practice: in theory, a DLL blacklist can't possibly work, but in practice, DLLs don't try hard enough to hide their existence from the blacklisting code. https://www.chromium.org/Home/third-party-developers#TOC-Goo...

Re: Inside Firefox’s DNS-over-HTTPS engine

#93

Post by geofft »

peterwwillis wrote: post #82
geofft wrote: post #22

Earlier quoted context omitted.

I specifically want DNS over HTTPS - except for specialized use cases over known networks where every device in between is tested as behaving properly, protocols that aren't TLS (over TCP) are a hassle to me both as an end user and as a developer, because someone is going to break them. And once you have TLS, there's little benefit in using something other than HTTP inside, and a lot of benefit in using something whe…

Why did you want this complicated hack when you could just use a SOCKS5 proxy to tunnel both your DNS and HTTP requests over a plain ssh connection on port 443? Or a TLS VPN on port 443 to properly tunnel all traffic (though admittedly it takes marginally more effort than ssh) ?

One, SSH on port 443 is not the same thing as HTTPS on port 443 (I've seen systems that block the former and not the latter).

Two, running a proxy to move all my browsing elsewhere seems like the hack. Changing the internet's norms so normal DNS is HTTPS-based, and everything just works everywhere for everyone, seems like a stable long-term solution.

Re: Inside Firefox’s DNS-over-HTTPS engine

#94

Post by ectospheno »

j0057 wrote: post #84

I'm not very happy we're now going to send all DNS traffic to 6 centralized DNS-over-HTTPS servers[1]. We can't trust our ISP, but we can trust Google and Cloudflare? I also noticed that when I configure my Android's proxy settings to point at a Privoxy container that routes through a VPN, I still get DNS-hijacked to my provider's "thepiratebay.org has been blocked for you" page -- this only happens in Chrome mobile,…

The good news is that blocking traffic to those six servers is trivial. You can stick the rule right after the one blocking traffic to port 853.

Re: Inside Firefox’s DNS-over-HTTPS engine

#95

Post by novaleaf »

Leon wrote: post #90
mike-cardwell wrote: post #79

I don't like the idea of this, but even the implementation is bad. If we're going to do DNS over HTTPS, then there should be a standalone application, and the system should be reconfigured to use it, so all running applications on the system use it. I mean, do we really want all of our desktop applications to have their own built in custom ways of mapping domain names to IP addresses? [edit] E.g on Linux, it could in…

There are lots of Open Source projects that will do what you are asking. Here is the first top hit on using bind to do that - https://github.com/wrouesnel/dns-over-https-proxy However I disagree that it is a bad idea and that the implementation is bad. Regardless of how software _should_ behave, Firefox operates in how software is actually run for their users. DNS is a source of security vulnerabilities and headaches…

I just spent some time searching, and I actually don't see much in the way of clients. Most search results seem to be talking about how wizz-bang dns-over-https is, or talking about firefox's implementation.

If you know of a DNS over HTTPS client for Windows, please link it!

Re: Inside Firefox’s DNS-over-HTTPS engine

#96

Post by davidu »

This further drives centralization of the Internet and the idea that the Internet == Web == Browser.

It's disappointing to see this coming from someone so steeped in Internet contributions and history and believing it to be a good idea.

Bypassing system DNS is not just an enterprise no-go, it probably will end up reducing privacy.

The idea that ISPs sniff DNS is largely a red-herring, and further it's already easily addressed by DNSCrypt or DNS over (d)TLS.

Re: Inside Firefox’s DNS-over-HTTPS engine

#97

Post by jedisct1 »

novaleaf wrote: post #95
Leon wrote: post #90

Earlier quoted context omitted.

There are lots of Open Source projects that will do what you are asking. Here is the first top hit on using bind to do that - https://github.com/wrouesnel/dns-over-https-proxy However I disagree that it is a bad idea and that the implementation is bad. Regardless of how software _should_ behave, Firefox operates in how software is actually run for their users. DNS is a source of security vulnerabilities and headaches…

I just spent some time searching, and I actually don't see much in the way of clients. Most search results seem to be talking about how wizz-bang dns-over-https is, or talking about firefox's implementation. If you know of a DNS over HTTPS client for Windows, please link it!

https://simplednscrypt.org/

Re: Inside Firefox’s DNS-over-HTTPS engine

#98

Post by eknkc »

dtech wrote: post #45
codewithcheese wrote: post #31

I am in Indonesia where Reddit, Vimeo, The Pirate Bay and other sites are blocked. I just enabled TRR in Firefox 60 (They mention best support is in 62) and now I have full unblocked access to all those sites. Awesome.

Using an alternative DNS resolver like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) could solve that already, and not only in Firefox.

They generally inspect DNS packets and block hostnames from resolving correctly. Does not matter the destination.

Re: Inside Firefox’s DNS-over-HTTPS engine

#99

Post by peterwwillis »

geofft wrote: post #93
peterwwillis wrote: post #82

Earlier quoted context omitted.

Why did you want this complicated hack when you could just use a SOCKS5 proxy to tunnel both your DNS and HTTP requests over a plain ssh connection on port 443? Or a TLS VPN on port 443 to properly tunnel all traffic (though admittedly it takes marginally more effort than ssh) ?

One, SSH on port 443 is not the same thing as HTTPS on port 443 (I've seen systems that block the former and not the latter). Two, running a proxy to move all my browsing elsewhere seems like the hack. Changing the internet's norms so normal DNS is HTTPS-based, and everything just works everywhere for everyone, seems like a stable long-term solution.

Everything already works everywhere for everyone with regular DNS. The only thing that is broken is firewalls. Specifically, nobody wants to force network administrators to fix them, so instead they're trying to work around them. Not only is this unnecessary, it's stupid, and just a cheap workaround for something which should have been solved by the industry 18 years ago, but is now left to be wrangled by 3 companies with leverage over users.

So I had a DNS server that used UDP. Now I need a DNS server and an HTTPS server that uses TCP. Now I'm encapsulating DNS in HTTPS. So now the packets are bigger and there's extra latency, increasing traffic and slowing things down. (These kind of "fixes" must be common, because I seem to notice how technology is constantly getting slower and crappier rather than the opposite)

Then there's security concerns, because you're running twice the software with greater complexity, yet it's subject to the same attack methods as everything else, meaning one exploit could impact DNS just as much as every other HTTPS service. Among these are attacks on the PKI system, which is fragile to say the least - an expired or revoked cert kills your DNS, and any CA can generate a cert (which apparently isn't hard to do using a BGP exploit) which can be used to circumvent the encryption. Since you need DNS to do anything on the net, it will be trivial to simply kill all DNS-over-HTTPS queries going over a network and force people to use a downgraded, insecure version of DNS. And you've got to handle encryption in a way that is normally for streams rather than datagrams - unnecessary for data which only really needs authenticity and integrity assurances (which is, again, already provided by DNSSEC)

Then there's reliability. You're tunneling DNS over a connection to one server. We already know this is slower, and we already know DNS is one of the factors that slows down page connections. So you had better hope that the one HTTPS endpoint you have a persistent pipelined connection to doesn't go down, or wait and wait for what you hope is an independent 3rd party's service that is also in your list of DNS-over-HTTPS resolvers to pick up the slack.

As a DNS admin, I had software that communicated with DNS servers. But now I have to rewrite everything to use DNS-over-HTTPS, because if a query fails in DNS-over-HTTPS, you have to troubleshoot the actual connection and not what you think is in DNS, or what you think DNS should be sending back to the client. So now I have to reinvent every DNS tool. And of course, for the enterprise DNS solutions that can't just magically sprout a new protocol extension, I'll need some sort of middleware software to map the DNS-over-HTTPS queries to the real DNS server.

All of this because someone wanted "privacy" of their DNS queries, and was too lazy to allow UDP packets greater than 512 bytes over their network.

Re: Inside Firefox’s DNS-over-HTTPS engine

#100

Post by jedisct1 »

kevincox wrote: post #69
KenanSulayman wrote: post #58

> [..] DOH increases privacy, security and sometimes even performance [..] Does anyone know how TLS over TCP can be faster than UDP?

I believe that big DNS responses will be faster because instead of establishing a TCP connection there is already a warm one ready to go. But yes, for the common case the performance will be the same.

UDP doesn't require any connection at all
Post reply on HN