💬 Discussion | Firefox eSNI / DoH/TRR #785

Closed
opened 2019-03-20 20:12:52 +00:00 by Mikaela · 15 comments
Mikaela commented 2019-03-20 20:12:52 +00:00 (Migrated from github.com)

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 3
  • network.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 to https://mozilla.cloudflare-dns.com/dns-query at least on official builds (I think Debian's firefox-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:

A small hobby ads block dns project with doh, dot, dnscrypt support.

DoT / DNS over TLS might also be worth discussing somewhere especially for Android users.

On the bottom there is a disclaimer:

Use at your own risk. Under no circumstances will the operator be held responsible or liable in any way for any claims, damages, losses, expenses, costs or liabilities whatsoever (including, without limitation, any direct or indirect damages for loss of profits, business interruption or loss of information) resulting or arising directly or indirectly from accessing or otherwise using this service (Blahdns server).
The operator does not guarantee in any way the access, availability and continuity of the functioning of this service. By using this website and service you consent to the disclaimer and agree to its terms and conditions.
By using Cloudflare this website stores a cookie, created and evaluated by Cloudflare.
This cookie is strictly necessary for Cloudflare's security features and cannot be turned off.

based on which I wouldn't recommend people to enforce DoH with trr mode 3.

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](https://en.wikipedia.org/wiki/Server_Name_Indication#Security_implications). The `about:config` options are mainly: * `network.trr.bootstrapAddress` - Normal DNS server to resolve the DoH URL in mode 3 * `network.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 to `https://mozilla.cloudflare-dns.com/dns-query` at least on official builds (I think Debian's `firefox-esr` has it empy by default) * `network.security.esni.enabled` [requires DoH](https://bugzilla.mozilla.org/show_bug.cgi?id=1500289) 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](https://blahdns.com/) which is using Cloudflare and describes itself as: > A small hobby ads block dns project with doh, dot, dnscrypt support. DoT / DNS over TLS might also be worth discussing somewhere especially for Android users. On the bottom there is a disclaimer: > Use at your own risk. Under no circumstances will the operator be held responsible or liable in any way for any claims, damages, losses, expenses, costs or liabilities whatsoever (including, without limitation, any direct or indirect damages for loss of profits, business interruption or loss of information) resulting or arising directly or indirectly from accessing or otherwise using this service (Blahdns server). > The operator does not guarantee in any way the access, availability and continuity of the functioning of this service. By using this website and service you consent to the disclaimer and agree to its terms and conditions. > By using Cloudflare this website stores a cookie, created and evaluated by Cloudflare. This cookie is strictly necessary for Cloudflare's security features and cannot be turned off. based on which I wouldn't recommend people to enforce DoH with trr mode 3.
Mikaela commented 2019-03-20 20:42:23 +00:00 (Migrated from github.com)

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.

Somehow I ended up reading [The big DNS Privacy Debate at FOSDEM](https://blog.powerdns.com/2019/02/07/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. ![](https://powerdnsblog.files.wordpress.com/2019/02/screenshot-from-2019-02-07-09-49-47.png?w=622&h=319)
beerisgood commented 2019-03-21 21:36:14 +00:00 (Migrated from github.com)
Another DoH / DoT server: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers

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[...]

@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.

>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[...] @OpenNIC only has one DoT server at the moment ([mine](https://servers.opennicproject.org/edit.php?srv=ns7.eng.gb.dns.opennic.glue)) 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.
Mikaela commented 2019-04-09 08:53:07 +00:00 (Migrated from github.com)

Firefox status update in another thread:

So, doing ESNI depends on being able to resolve TXT records.
Due to the fact that the ability to do this varies greatly from platform to platform, Firefox only supports it via DoH, which is platform independent.
...
In any case, this isn't high priority. I don't see it being fixed too soon unless someone volunteers a patch.

Bug 1542754 eSNI on Android 9 (using DoT from android)

Firefox status update in another thread: > So, doing ESNI depends on being able to resolve TXT records. > Due to the fact that the ability to do this varies greatly from platform to platform, Firefox only supports it via DoH, which is platform independent. > ... > In any case, this isn't high priority. I don't see it being fixed too soon unless someone volunteers a patch. [Bug 1542754 eSNI on Android 9 (using DoT from android)](https://bugzilla.mozilla.org/show_bug.cgi?id=1542754#c3)
Atavic commented 2019-04-12 20:45:13 +00:00 (Migrated from github.com)
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
Mikaela commented 2019-04-13 13:44:42 +00:00 (Migrated from github.com)

I cannot find network.security.esni.enabled on either page you linked.

I cannot find `network.security.esni.enabled` on either page you linked.
Atavic commented 2019-04-13 22:10:13 +00:00 (Migrated from github.com)

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!"

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!*"
ilhanyumer commented 2019-04-22 17:17:52 +00:00 (Migrated from github.com)

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.

`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.
ilhanyumer commented 2019-04-22 17:35:46 +00:00 (Migrated from github.com)

DoH

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.

nslookup wikipedia org

![DoH](https://user-images.githubusercontent.com/762377/56513846-5a5d0700-653c-11e9-83a1-44c2c1e3b54c.png) 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. ![nslookup wikipedia org](https://user-images.githubusercontent.com/762377/56514410-d7d54700-653d-11e9-890d-41c0ea50be2f.png)
Mikaela commented 2019-07-03 21:16:41 +00:00 (Migrated from github.com)

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 referred here [from the forum](https://forum.privacytools.io/t/dns-and-isp/1049/3?u=mikaela) 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?
Atavic commented 2019-07-04 18:59:52 +00:00 (Migrated from github.com)

I'm against it and the issue for me is centralization; it is well explained here.

I'm against it and the issue for me is centralization; it is well explained [here](https://tools.ietf.org/id/draft-livingood-doh-implementation-risks-issues-03.html#Centralization).
Mikaela commented 2019-07-04 20:17:15 +00:00 (Migrated from github.com)

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?

Your link also gives good news to me: * [ 3. Network Operators Are Interested in Deploying DoH](https://tools.ietf.org/id/draft-livingood-doh-implementation-risks-issues-03.html#rfc.section.3) * [ 10. Recommendations ](https://tools.ietf.org/id/draft-livingood-doh-implementation-risks-issues-03.html#rfc.section.10) * > Develop a Standardized DoH Resolver Discovery and Selection Mechanism: * I think DoT has something like this, but I will need to read up on what it's officially. * Edit: it's called as opportunistic profile and it might not perform certificate validation, which is done with strict where hostname is specified. [RFC 8310 section 5](https://tools.ietf.org/html/rfc8310#section-5) via [Google Public DNS over TLS documentation](https://developers.google.com/speed/public-dns/docs/dns-over-tls) * > Conventional DNS Providers Should Begin Testing DoH: * > Defaults Matter - Consider Them Carefully: 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?
Atavic commented 2019-07-13 20:13:48 +00:00 (Migrated from github.com)

A warning about default choices in Firefox is needed, maybe expanding the section under
Firefox user.js Templates

A warning about default choices in Firefox is needed, maybe expanding the section under *Firefox user.js Templates*
Mikaela commented 2019-07-24 07:29:41 +00:00 (Migrated from github.com)

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?

Judging by [censoredplanet's Kazakhstan research](https://censoredplanet.org/kazakhstan) 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?](https://forum.privacytools.io/t/when-governments-openly-mitm-what-could-go-wrong/1131?u=mikaela)
Mikaela commented 2019-08-01 14:07:55 +00:00 (Migrated from github.com)

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.

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.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#785
No description provided.