search

arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
9.96k stars 511 forks source link

ToDo: DoH section or entries #1027

Closed Thorin-Oakenpants closed 3 years ago

Thorin-Oakenpants commented 3 years ago

My first impression is that it needs it's own section, as there are quite a few prefs - the main one of course is to block the rollout by default (AFAIK there is a notification panel allowing you to cancel, or at least to let you know). I think the rollout has been limited to the USA so far - but at some stage they will flip it for a lot more (not sure how that works - since I assume most arkenfox English users install en-US builds?)

This is not a debate on this state = good, this state = bad. There are pros and cons to both. It's more about what prefs to add, references, and so on. My initial thoughts are the section header can have some references/info on whether or not DoH is for you (pros/cons) as everyone's threat model will differ, and we can dispel some myths or whatever. And then the only active pref is to block the rollout - thus putting the choice in the hands of the end-user, not some rollout. All other prefs are for those who want to setup their DoH config and use it.

After lots of teething issues and shitloads of bugs and changes, I think DoH is finally ready. IANAE on this shit, so help is appreciated, especially from those using it who know the pitfalls and what configs screw things up etc

FYI: DoH + CNAME cloaking is finally fixed in ESR78.4 and FF82

It's things like this bug, and constant new prefs and pref changes and UI changes etc, why I never wanted to have a DoH section/entries and dealing with the inevitable fallout/issues and it's why I removed what we had about a year ago or whenever it was .. but now I think we can look at adding it back in

edit: typos

seonwoolee commented 3 years ago

I run a private DNS server using AdGuardHome and I've got it set up to accept DNS, DoT, and DoH requests. I've got all my browser profiles set up to use my AdGuardHome instance via DoH.

I cannot for the life of me get Firefox to recognize the network.trr.mode preference set in user.js. It is 100% set in user.js but never gets written to prefs.js. Maybe there is some other setting I need to change for Firefox to capture it from user.js, but If there is I haven't found it.

seonwoolee commented 3 years ago

Oh also if you want to enable encrypted SNI, you must have DoH enabled; otherwise the network.security.esni.enabled preference has no effect whatsoever.

In my opinion this is somewhat well intentioned but ultimately also somewhat annoying. Yes, if you ultimately don't use DoH which site you're visiting is leaked anyways. But someone could be using a local DNS server that accepts regular DNS requests and forwards them over DoH or DoT.

rusty-snake commented 3 years ago

FWIW: My DoH overrides

/*** [SECTION 6750]: DoH ***/
/* 6751: DoH mode ***/
   // user_pref("network.trr.mode", 2); // enable TRR (with System fallback)
user_pref("network.trr.mode", 3); // enable TRR (without System fallback)
   // user_pref("network.trr.mode", 5); // Disable TRR
/* 6752: DoH resolver
 * The second pref is optional for DoH mode 2 and required for mode 3 ***/
user_pref("network.trr.uri", "https://xxxx/dns-query");
user_pref("network.trr.bootstrapAddress", "x.x.x.x");
/* 6753: DoH resolver list
 DEFAULT(72): [{ "name": "Cloudflare", "url": "https://mozilla.cloudflare-dns.com/dns-query" }]
 DEFAULT(73): "[{ \"name\": \"Cloudflare\", \"url\": \"https://mozilla.cloudflare-dns.com/dns-query\" },{ \"name\": \"NextDNS\", \"url\": \"https://trr.dns.nextdns.io/\" }]"
***/
   // user_pref("network.trr.resolvers", "[{ \"name\": \"<NAME1>\", \"url\": \"https://<URL1>\" }, { \"name\": \"<NAME2>\", \"url\": \"https://<URL2>\" }]");
/* 6754: ***/
user_pref("network.dns.skipTRR-when-parental-control-enabled", false);
/* 6755: enable ESNI
 * ESNI has nothing to do with DoH, but the implementation in Firefox requires it ***/
user_pref("network.security.esni.enabled", true);

I ignored other prefs such as

seonwoolee commented 3 years ago

@rusty-snake did setting network.trr.mode in your user.js actually work for you? Because I've never gotten it to work - I've always had to set it in prefs.js

2glops commented 3 years ago

Linux Debian testing - Firefox 80.0.1 64bits My DoH settings, about:config modifications :

user_pref("network.trr.mode", 2); user_pref("network.trr.uri", "https://xxxx/dns-query"); user_pref("network.trr.bootstrapAddress", "x.x.x.x"); user_pref("network.dns.skipTRR-when-parental-control-enabled", false); user_pref("network.security.esni.enabled", true); user_pref("network.trr.blocklist_cleanup_done", true); user_pref("network.trr.custom_uri", "https://xxxx/dns-query");

I pick my DoH server from : https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers

rusty-snake commented 3 years ago

@seonwoolee WFM

seonwoolee commented 3 years ago

That's interesting. What system are you running this on? I'm using the latest Firefox on Arch Linux

rusty-snake commented 3 years ago

Fedora 32 with firefox from page sources. Does it work to set any other pref from this user.js? Is there no typo?

Svallinn commented 3 years ago

FYI: out of topic @seonwoolee network.trr.mode WFM as well do you mind testing something for me? In case you have search bar enabled in your firefox, disable it in your preferences inside the browser and exit it Then add this:

user_pref("browser.search.widget.inNavBar", true); // enable search bar

to your user.js, boot up firefox again and tell me if the search bar pops up or not, because when I do this, it doesn't pop up for me I have this problem on archlinux, but I've had it in other distros as well

rusty-snake commented 3 years ago

https://www.reddit.com/r/firefox/comments/b6zebm/some_config_settings_dont_seem_to_apply_from/

Svallinn commented 3 years ago

@rusty-snake thank you for that, I guess I should've searched it up better

seonwoolee commented 3 years ago

@rusty-snake I have a ton of prefs in user.js that work, just not this one. 100% positive it is not a typo.

rusty-snake commented 3 years ago

Changing it in about:config or prefs.js works and passes a restart, right? Can you try it in a new, clean, empty profile.

Thorin-Oakenpants commented 3 years ago

I cannot for the life of me get Firefox to recognize the network.trr.mode preference set in user.js

This reminds me of https://github.com/arkenfox/user.js/issues/952#issuecomment-643322391 , where the package was "interfering"

seonwoolee commented 3 years ago

Yes, changing it in about:config and prefs.js works and passes a restart.

I already tested this in a brand new profile. Still can't get Firefox to accept the network.trr.mode value set in user.js

Didn't know about vendor.js but that isn't (or at least shouldn't be) the source of the problem:

$ cat vendor.js
// Use LANG environment variable to choose locale
pref("intl.locale.requested", "");

// Use system-provided dictionaries
pref("spellchecker.dictionary_path", "/usr/share/hunspell");

// Disable default browser checking.
pref("browser.shell.checkDefaultBrowser", false);

// Don't disable extensions in the application directory
pref("extensions.autoDisableScopes", 11);
rusty-snake commented 3 years ago

Nothing in it: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox.

It could also be policies.json or network.dns.skipTRR-when-parental-control-enabled.

Still can't get Firefox to accept the network.trr.mode value set in user.js

Which value?

seonwoolee commented 3 years ago 
$ cat /usr/lib/firefox/distribution/policies.json  | grep network
      "geo.provider.network.url": "",
      "browser.region.network.url": "",
      "network.connectivity-service.enabled": false,
      "network.prefetch-next": false,
      "network.predictor.enabled": false,
      "network.predictor.enable-prefetch": false,
      "network.http.speculative-parallel-limit": 0,
      "network.IDN_show_punycode": true

I'm setting it to 3.

Well I'm getting somewhere. If I create a fresh profile and create a single line user.js with just network.trr.mode set to 3, it gets set properly. If I use my custom user.js, which has a bunch of other preferences alongside network.trr.mode set to 3, it doesn't work. And I've made sure I'm not overwriting the preference by setting it multiple times:

$ grep network.trr.mode < user.js
user_pref("network.trr.mode", "3");

Binary search time to find which preference is causing a conflict.

Svallinn commented 3 years ago

Honestly, this only happened to me a single time and it was when I had this mysterious red dot displayed on my Notepad++, it was apparently a character of some sort I put in accidentally and it was screwing up the pref right next to it I was pissed off because I went at it for hours when the cause was "right there"...

seonwoolee commented 3 years ago

Never mind, I was an idiot and forgot I need to clear the pref in pref.js first.

Even if I

  1. Create a brand new profile
  2. Use a single line user.js with just user_pref("network.trr.mode", "3");

Firefox still uses network.trr.mode of 0.

I also tried a two line user.js, with 

user_pref("network.trr.mode", "3");
user_pref("network.dns.skipTRR-when-parental-control-enabled", false);

The parental control preference was recognized while network.trr.mode was not

rusty-snake commented 3 years ago

grep network.trr.mode < user.js

OT: You can also let grep open the file, no need for a <: grep network.trr.mode user.js

user_pref("network.trr.mode", "3");

This is an integer, works it if you use user_pref("network.trr.mode", 3); instead.

seonwoolee commented 3 years ago

And...I'm an idiot.

I was putting "3", not 3. Firefox was rejecting it as a string.

Sorry for all the ruckus.

atomGit commented 3 years ago

perhaps the bigger question is whether Mozilla should be messing with DNS at all

personally i find this fucking offensive, period

this should be done at the OS level, or per application at the users discretion

i really think the broader picture of Mozilla's goals need to be considered here and given the avenues they've been perusing, and rightfully getting their fucking teeth kicked in for, i don't want them messing with DNS

crssi commented 3 years ago

OS level is also a shit due to multihomed name resolution in windows leading to DNS leak. 😞

atomGit commented 3 years ago

well i'm sure this will offend some here, but it shouldn't; if we're interested in privacy, at all, then we're sure as hell not running windoze

Thorin-Oakenpants commented 3 years ago

stay on topic please: reminder from the first post: This is not a debate on this state = good, this state = bad

Thorin-Oakenpants commented 3 years ago

FYI: seems like 1544233: DoH +hosts file was resolved in FF83 by 1616252 .. so that's good. More parity, possible holes fixed etc

iio7 commented 3 years ago

I would very much like to see a default of disabling DoH in this. I think it is only a matter of time before Mozilla starts to roll this out as default enabled. On our network we block DoH, but we also use a default user.js based upon the Arkenfox and having this set here helps a lot.

Thorin-Oakenpants commented 3 years ago

@iio7 that's easy enough ... just set user_pref("network.trr.mode", 5); .. 5 is an explicit do not roll out. That would help with multiple profiles. Otherwise my understanding is that a user gets a doorhanger prompt before DoH is flicked on, and they can cancel it

Thanks @rusty-snake @2glops for your configs 👍

ANYONE ELSE .. and I can't stress this enough ... NOW IS THE TIME TO CONTRIBUTE ... links on how DoH, ESNI, bugzillas, what works and what doesn't, known bugs, your configs, anything. It would be cool to get this issue resolved and out of the way. Thanks

Thorin-Oakenpants commented 3 years ago

good article/summary: https://www.eff.org/deeplinks/2020/12/dns-doh-and-odoh-oh-my-year-review-2020

Thorin-Oakenpants commented 3 years ago

note: network.security.esni.enabled removed in FF85 edit: https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

gitthehubs commented 3 years ago

Securing DNS is a good thing, although it can conflict with some anti virus applications that check DNS traffic. The question is more if using the current DoH implementations in internet browsers is the best solution? Personally I don't think it is wise the redirect DNS traffic from internet browsers to just a few DNS providers, it centralises DNS for the internet browsers to just a few DNS providers and that is my main concern. The best solution, in my opinion, would be that the operating system is supporting secure DNS protocols and that the DNS servers from your internet provider supports secure DNS protocols. Sadly is not going very well, there are operating systems that do support secure DNS protocols, but the other server part on the internet providers don't seem to go very quickly in supporting secure DNS. I know android support DoH, I have red IOS 14 and MacOS would support DoH and DNSoverTLS. I know Linux is supporting it(if I'm right). Microsoft is wirking on implementing DoH in Windows 10, but not yet officially released.

Another issue is that current DoH providers in internet browsers don't always redirect you to the nearest datacenter where you local DNS servers from your providers do(I assume). I noticed that with some social media site I got redirected to another country while that web site had it's own datacenter in my own country.

So personally I don't use Firefox' DoH.

I do use secure DNS, but I run my own DNSCrypt application and use multiple secure, DNSCrypt, DNSSEC, no logging, no filtering, DNS servers in my own country to load-balance my DNS queries to.

gitthehubs commented 3 years ago

@Thorin-Oakenpants

note: network.security.esni.enabled removed in FF85 edit: https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

Are you, and if so when, going to add these new prefs? user_pref("network.dns.echconfig.enabled", true); user_pref("network.dns.use_https_rr_as_altsvc", true);

Thorin-Oakenpants commented 3 years ago

IDK, are they somehow important?

gitthehubs commented 3 years ago

IDK, are they somehow important?

Well, read your own link. :stuck_out_tongue: 😄 https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

But, quote:

Though we recommend that users wait for ECH to be enabled by default, some may want to enable this functionality earlier.

But I don't know how long that will take, users who already used the pref network.security.esni.enabled:true can consider to enable ECH already manually.

Thorin-Oakenpants commented 3 years ago

this is not something that is going to happen any time soon, DoH is super low priority and I refuse to do it myself - hence why I nagged you to say why they are important: read OP, why do I have to always do everything, including looking it up and searching for how it is used in DoH and all that - there was an earlier smallish DoH prefs in the user.js about two years ago which in the end I ripped out precisely because I was left holding the bucket, and there were too many bugs/changes - I'm not going back to that

rusty-snake commented 3 years ago

BTW: Does anyone know if/how network.dns.use_https_rr_as_altsvc conflicts with 0703 where network.http.altsvc.enabled=false. This should be checked too, if you add it to your user(-overrides).js.

2glops commented 3 years ago

DoH, ODoH, xDoH ?

For sure, it's time to wait and see : https://blog.cloudflare.com/oblivious-dns/ https://techpp.com/2020/12/14/odoh-oblivious-dns-over-https-explained/

gitthehubs commented 3 years ago

@Thorin-Oakenpants

I was just a little bit confused why you asked if the new prefs were somewhat important. Because the user.js had the pref network.security.esni.enabled it was sort of logical, well to me, to use the new prefs for ECH, ECH is the successor of ESNI. And because you added the link to the article about ECH replacing ESNI I was just wondering if you red your own link else you wouldn't ask if the new prefs were somewhat important, well that was my thinking. If you used ESNI you would now want to use ECH is my opinion. But maybe I interpreted the question wrong, was it in general speaking or did you ask for my personal opinion. Maybe I went wrong on that. Sorry if so. I hope this clarifies it a bit. 😄

And FYI, I did read the OP, I was merely commenting on it because you commented about removing the ESNI pref network.security.esni.enabled from the user.js. It triggerd me to ask if the ECH prefs should be added as a replacement. And I gave my opinion about the new ECH prefs, but I must agree it may not be that clear. I quote:

But I don't know how long that will take, users who already used the pref network.security.esni.enabled:true can consider to enable ECH already manually.

If you used ESNI you now want ECH and don't wait till Mozilla makes it default. Although I understand it is a TLS 1.3 extension and web servers have to support it, but that was the case with ESNI also that web servers have to support it.

this is not something that is going to happen any time soon, DoH is super low priority and I refuse to do it myself - hence why I nagged you to say why they are important

FYI2, ESNI/ECH have nothing to do with DoH. ESNI/ECH are TLS extensions. It are two different ways to hide which site you are visiting, one is in the DNS traffic and the other is in the TLS traffic.

e.g. this issue is already five months old and it's gotten nowhere. AFAIC, it's a dead issue, but I'll leave it open here for all eternity

I noticed this, but because of the 'recent' comments in january I though it was ok to comment and give my thought about DoH. You asked for input, I gave mine.

rusty-snake commented 3 years ago

FYI2, ESNI/ECH have nothing to do with DoH. ESNI/ECH are TLS extensions. It are two different ways to hide which site you are visiting, one is in the DNS traffic and the other is in the TLS traffic.

Firefox esni implementation required DoH to be enabled. With network.security.esni.enabled=true and network.trr.mode=0 (or 5) esni was disabled.

gitthehubs commented 3 years ago

@rusty-snake

Firefox esni implementation required DoH to be enabled. With network.security.esni.enabled=true and network.trr.mode=0 (or 5) esni was disabled.

That is done by Mozilla, it has no use of encrypting you SNI while your DNS is not encrypted and still exposing which site you are visiting.

gitthehubs commented 3 years ago

@rusty-snake

BTW: Does anyone know if/how network.dns.use_https_rr_as_altsvc conflicts with 0703 where network.http.altsvc.enabled=false. This should be checked too, if you add it to your user(-overrides).js.

I could be wrong, so no guarantees. But I would say it are two different things. network.http.altsvc.enabled https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Alt-Svc

The Alt-Svc HTTP response header is used to advertise alternative services through which the same resource can be reached. An alternative service is defined by a protocol/host/port combination.

network.dns.use_https_rr_as_altsvc https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

ECH also changes the key distribution and encryption stories: A TLS server supporting ECH now advertises its public key via an HTTPSSVC DNS record, whereas ESNI used TXT records for this purpose.

Thorin-Oakenpants commented 3 years ago

Because the user.js had the pref network.security.esni.enabled

never had it, doesn't have it now. I only mentioned it was being removed since it was in rusty's overrides

gitthehubs commented 3 years ago

@Thorin-Oakenpants

never had it, doesn't have it now. I only mentioned it was being removed since it was in rusty's overrides

Than that is a misunderstanding on my side, sorry for that. I had the pref in my personal user.js, so I assumed it came from your user.js, apparently I had the pref from somewhere else.

rusty-snake commented 3 years ago

@gitthehubs you seem to be right. Looks like it is inspired by AltSvc but different. (https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-httpssvc-03.html#name-relationship-to-alt-svc).

Thorin-Oakenpants commented 3 years ago

https://blog.mozilla.org/en/mozilla/news/firefox-by-default-dns-over-https-rollout-in-canada/

so after 2+ years .. rollout is so far .. USA .. and Canada about to start .. so glad I ignored all of this for 2 + years

Thorin-Oakenpants commented 3 years ago

doh-rollout.home-region will reveal your region

My main FF (portable with user.js) shows US - I suspect from the fact that it is A) an en-US build B) prefs in user.js force me to en-US and region updates are disabled (I am not US) - see section 0200. In my portable test FF's, which are practically vanilla for testing, the pref value is my real country

Not sure why I've never seen a prompt or been rolled out to: maybe from the old pref when it was in the user.js, or maybe I had the xpi removed (I don't bother anymore as it forces a full download to update via the app)

So sorry all you sucker loser en-US arkenfox users, while I was busy working from early in the morning until late in the evening and making many phone calls and having many meetings, the boat sailed (probably from Florida full of superspreaders) and you were already rolled out .. lulz 🤣

I plan to close this before release 91 (for ESR). I will add the basic rollout pref (inactive), point to the UI, and reference some links. That's it. Just giving you all the heads up in case anyone wants to add anything after 2+ years

Thorin-Oakenpants commented 3 years ago

notes to self:

@rusty-snake I don't use DoH because I live in a utopian non-shit non-3rd-world country which values privacy ... do you have any other links or info, like test pages - etc - e.g. https://old.reddit.com/r/privacytoolsIO/comments/cplstn/doh_confirmation_test/ ?

rusty-snake commented 3 years ago

Actually you can use any dns-leak test like https://browserleaks.com/dns or https://www.dnsleaktest.com/ though the results can be confusing.

There are two support pages, not sure if they are relevant. https://support.mozilla.org/en-US/kb/firefox-dns-over-https https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs

https://www.cloudflare.com/ssl/encrypted-sni/

Since firefox remove esni, ...