Live data from Hacker News

Firefox’s Trusted Recursive Resolver DNS feature is dangerous

blog.ungleich.ch

211–220 of 306 posts

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#211
post #62
post #22

The article lacks instructions about disabling it or using some other DOH resolvers. about:config -> search for network.trr -> set network.trr.mode = 5 to completely disable it (I do not recommend this) The curl wiki has a list of DOH servers: https://github.com/curl/curl/wiki/DNS-over-HTTPS It should also point to "the other side of the story", the benefits of DOH over classic DNS resolving, for example https://hack…

Thanks for the hint! We added that to our blog entry - please let us know if it sounds right to you.

You're operating under the assumption that if this is turned on by default in the future, everything will go to CloudFlare.

While CloudFlare is being used for the opt-in study, you have no evidence that they will be used in any on-by-default scenario. Nor do you have any evidence that only a single DoH provider will be used globally.

Perhaps you should monitor Mozilla mailing lists.

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#212
post #21

Earlier quoted context omitted.

Your home router will. However, as the article made clear, you won't be able to open that site in Firefox. Even if you were, you won't be able to get a public TLS certificate for that site, making you unable to serve the site as HTTPS and locking you out of many current and all(!) futue JS and CSS features. Yes, you can solve both problems by installing overrides. However, this has to be done separately for every cli…

My home router will. My browser will also open the site. My browser might not necessarily be Firefox, though. For internal sites, you don't need public TLS cert. If your device is joined to a domain, you already have a private CA cert installed, so whoever controls that domain, can make certs for its resources. If you do that at home, it is no problem to make your own CA and use it for your home resources. It is just…

> For internal sites, you don't need public TLS cert. If your device is joined to a domain, you already have a private CA cert installed

Thanks for that info, I wasn't aware of that. However, to my knowledge, Firefox doesn't use the OS trust store but its own. So for clients using Firefox, you'd still have to install the cert, wouldn't you?

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#213
Just because what you're doing is private doesn't mean it's secure. Just because what you're doing is secure doesn't mean it's private.

No whistleblower should ever just expect that doing things the normal way is private or safe for them. If you wear a tinfoil hat, you need an entirely different operational language than typical users have, because your needs are totally different.

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#214

Earlier quoted context omitted.

FF will turn this on for everybody and Cloudflare will be the default 2018? Don't know. 2019? For sure. All FF browsing meta data flows into the US, the country with the most spies and no legal framework to go to court. So your argument is an obvious straw man and one wonders about your motivations to support getting all the browsing meta data into the US by default. Moving my data from Germany to the US will not mak…

Why do you believe that this will be default on at any time in the near future without a reasonable configuration UI and without a reasonable set of DoH-capable nameservers? Especially given that this would break a substantial number of existing setupts? If you have this little faith into the FF/Mozilla folks, why do you keep using FF? If you’re not using Firefox, what are you concerned about?

If they don't turn it on by default, only a small number of people will use it. If only a small number of people use it, why bother implementing it?

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#215
post #7

What about if you have private DNS servers that has sites that cloudflare does not have? For example internal intranets etc? So mozilla will not work at all in that case?

The expected common deployment mode is soft fallback - using traditional DNS if connections cannot be made via the DoH resolved address. Captive portal provides the most common use case. There is a hard failure mode available that you can use for better security if you're in a vanilla Internet environment - but we don't see a way to broadly offer that choice other than in technical documentation.

Thanks for answering questions in this thread. This makes a lot more sense - so LAN-only names would still resolve then.

This still seems like it could cause problems in certain circumstances, e.g.:

- The local DNS server deliberately does not resolve certain hosts (e.g. because it's running PiHole)

- An internal host also happens to resolve on the external DNS, though with a different IP. E.g., a company could have its public DNS set to a catchall entry *.company.com, but at the same time could have dev.company.com set to a special IP inside the LAN. This setup seems also required if you want to use Let's Encrypt internally.

Those scenarios seem difficult to manage, because they are potentially indistinguishable from attacks. Do you have any solution for that?

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#216
post #212

Earlier quoted context omitted.

My home router will. My browser will also open the site. My browser might not necessarily be Firefox, though. For internal sites, you don't need public TLS cert. If your device is joined to a domain, you already have a private CA cert installed, so whoever controls that domain, can make certs for its resources. If you do that at home, it is no problem to make your own CA and use it for your home resources. It is just…

> For internal sites, you don't need public TLS cert. If your device is joined to a domain, you already have a private CA cert installed Thanks for that info, I wasn't aware of that. However, to my knowledge, Firefox doesn't use the OS trust store but its own. So for clients using Firefox, you'd still have to install the cert, wouldn't you?

For the ESR release, you can use Group policy (Windows only) or policies.json (all systems) to make it accept the system cert store.

For all releases, you can make the process of joining the domain to also include installing the cert into Firefox's store. For example, the Redhat's ipa-client-install does install the certificate into the Firefox store by default.

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#217

> My local ISP seems more trustworthy to me than a big US-based corporate which acts under the guise of a selfless privacy rights defender. I have never trusted any local ISP. They’re commonly expressly allowed by law to share roughly whatever they like about you†, and they are known to do so . Cloudflare has at least promised not to be evil, and is to be audited annually concerning it. If they desire to be evil I ha…

but your ISP will still be able to see all your connections even if you don't use its DNS servers unless you use a VPN... this just spreads the information to a third party.

https://en.wikipedia.org/wiki/Server_Name_Indication#Securit...

Downvote me all you want, but domain names are still being sent to the ISP unencrypted, as of TLS 1.3... so it doesn't matter who processes your DNS queries, your ISP still knows everything about which sites you are accessing... but anyways, bare IP addresses still reveal a lot (metadata)

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#218
post #158

Earlier quoted context omitted.

Actually, yes, I do. From their blog: > We believe that negotiating a privacy first operating agreement is something that Firefox can do for people that is just impractical to ask them to do for themselves. Imagine calling up your residential ISP and asking them to agree to an audit that demonstrates they do not log your IP address on their DNS server. And then repeating the process for your favorite coffee shop, lib…

And you expect that to happen within the next month? Without any warning that it will happen with the 62 release? After they have just started an experiment intended to shake down the feature on both the server and the client side? Even after having it default off in nightly? With no practical experience of how a large-scale DoH setup behaves in a real-world environment? Breaking all setups that use an internal DNS t…

Hmm, looks as if the September date was indeed an error - even the article added a correction. (Also a Mozilla representative seemed to post they plan to keep local DNS as fallback)

So I do hope you're right and they will take their time until the ecosystem stabilizes and they found less damaging strategies.

I still think there are general problems with DoH and the assumption that all local networks are hostile. But maybe, there will be more time to discuss those assumptions.

I don't see that they will necessarily add a config GUI though. Most people will likely ignore the feature and the techies already have about: config, so there might be little pressure to add a more accessible UI.

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#219

Just because what you're doing is private doesn't mean it's secure. Just because what you're doing is secure doesn't mean it's private. No whistleblower should ever just expect that doing things the normal way is private or safe for them. If you wear a tinfoil hat, you need an entirely different operational language than typical users have, because your needs are totally different.

Privacy improves security for everybody. If an attacker can read all your DNS lookups then it's easier for them to target a spear-phishing attack against you.

Re: Firefox’s Trusted Recursive Resolver DNS feature is dangerous

#220

Earlier quoted context omitted.

but your ISP will still be able to see all your connections even if you don't use its DNS servers unless you use a VPN... this just spreads the information to a third party.

https://en.wikipedia.org/wiki/Server_Name_Indication#Securit... Downvote me all you want, but domain names are still being sent to the ISP unencrypted, as of TLS 1.3... so it doesn't matter who processes your DNS queries, your ISP still knows everything about which sites you are accessing... but anyways, bare IP addresses still reveal a lot (metadata)

right - but we're coming for cleartext sni too:

https://tools.ietf.org/html/draft-rescorla-tls-esni-00

interestingly, something like DoH is a pre-requisite for pulling off esni.

Post reply on HN