💬 Discussion | Firefox eSNI / DoH/TRR #785
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#785
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I noticed that PrivacyTools.io doesn't mention Firefox's support for DNS over HTTPS (which it calls as Trusted Recursive Resolver or TRR) or encrypted SNI.
The
about:config
options are mainly:network.trr.bootstrapAddress
- Normal DNS server to resolve the DoH URL in mode 3network.trr.mode
- The values I remember are 0 to currently disable, 2 to use DoH before falling back to system DNS. 3 to only use DoH and 5 to explicitly disable (hinting that 0 may change meaning)network.trr.uri
- defaults tohttps://mozilla.cloudflare-dns.com/dns-query
at least on official builds (I think Debian'sfirefox-esr
has it empy by default)network.security.esni.enabled
requires DoH and doesn't currently exist in ESR as far as I am aware.The feature is a bit controversial as it bypasses what the system/network administrator has configured and sends everything to Cloudflare (https://github.com/privacytoolsIO/privacytools.io/issues/374) when enabled and there being network.trr.mode 5 for explicit disabling hints that it's going to get enabled at some point.
Should PrivacyTools.io contain something about these options on the Firefox about:config section? (Sorry for bold, it just seems like I wrote too long story after this paragraph to not bold it) I think it's a security feature when I am aware of it and configure it by myself, especially when used together with encrypted SNI to hide better which sites I am visiting, but I think here at least the Cloudflare part is going to provoke discussion.
Currently the only mentioned DNS provider is OpenNIC and quickly trying to find a OpenNIC DoH provider I only find Blahdns which is using Cloudflare and describes itself as:
DoT / DNS over TLS might also be worth discussing somewhere especially for Android users.
On the bottom there is a disclaimer:
based on which I wouldn't recommend people to enforce DoH with trr mode 3.
Somehow I ended up reading The big DNS Privacy Debate at FOSDEM, I have no idea where I found the link from, and it seems that this discussion has already been had and they have a nice picture. I warmly recommend reading it.
Another DoH / DoT server:
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
@OpenNIC only has one DoT server at the moment (mine) which is kind of experimental. Just thought I'd mention it though, we are working on it!
Edit: I should mention, we only have the one officially, i.e. on the OpenNIC Public Server page. I'm sure there's more that support DoT and use our root but I wouldn't know about them.
Firefox status update in another thread:
Bug 1542754 eSNI on Android 9 (using DoT from android)
It still leaks the SNI, that's a tracking opportunity in clear-text, see:
https://daniel.haxx.se/blog/2018/06/03/inside-firefoxs-doh-engine/
https://gist.github.com/bagder/5e29101079e9ac78920ba2fc718aceec
I cannot find
network.security.esni.enabled
on either page you linked.You can enable it, but encrypted SNI is still a draft on IETF, just look at the 1st link above; once on daniel.haxx page, search for: "It still leaks the SNI!"
network.security.esni.enabled
requires TLS 1.3 on server-side. And it works. Turkish ISPs block web sites by sniffing SNI. If you enable esni in Firefox and the web site uses TLS 1.3 then you can access blocked web sites. I've tested it, it works.There are many DNS over HTTPS servers. The image above shows 12 of them (by the way I don't use Simple DNSCrypt, I use Firefox's build in one). Also I don't understand why you are frustrated with DoH. Which one is worse? Being tracked by a foreign company or being tracked by your government? Turkish ISPs hijack classic DNS queries since they are plain text on the wire. By law they log all DNS queries for few years. Moreover if the domain is in the black list, it doesn't matter if you use 8.8.8.8 or your local DNS the
nslookup
doesn't respond and you cannot reach the web site (see the image below). That is why DoH is more secure than plain-text DNS queries.I referred here from the forum and wonder does anyone have ideas to this issue?
Is it better to pretend that TRR/ESNI doesn't exist or should they be listed on the website with warnings?
I guess there would also be a prerequirement of recommending a DNS over HTTPS server to use?
I'm against it and the issue for me is centralization; it is well explained here.
Your link also gives good news to me:
so I hope the centralization issue can be fixed before DoH becomes wideespread, but there is still the issue on what should be listed on PTIO especially regarding ESNI (even if it's currently a draft and only implemented by Firefox and Cloudflare in some form).
I guess another option could be adding warnings about Firefox possibly going to default to Cloudflare advicing disabling TRR and also adding a warning that disabling it also disables ESNI and linking to the two upstream issues?
A warning about default choices in Firefox is needed, maybe expanding the section under
Firefox user.js Templates
Judging by censoredplanet's Kazakhstan research I get the impression that their national MITM can currently be evaded by using ESNI, but I am not sure if any of their listed MITMed domains supports that.
Forum thread: When governments openly MITM what could go wrong?
I think this issue has gotten unblocked, but I wish to fix/PR https://github.com/privacytoolsIO/privacytools.io/issues/1077 first, so there is more user choice and hopefully providers without warnings.