search

arkenfox / user.js

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

CRLite seems not to work #1811

Closed brokoler closed 7 months ago

brokoler commented 7 months ago

Arkenfox switched to a new certificate revocation check mechanism, it now uses CRLite instead of OCSP per default. This is appreciated, since CRLite offers many advantages. Right now it seems not to work compared to a Firefox install without Arkenfox.

Default behavior with CRLite enabled: security.remote_settings.crlite_filters.enabled = true Firefox downloads multiple files required and saves them in the user profile folder inside sub-folder "security_state". Certificate revocation checks based on CRLite are only working, when these files were downloaded successfully.

Mozilla explains the feature in detail: Certificate revocation checks are only performed via CRLite after specific files were downloaded: https://blog.mozilla.org/security/2020/01/09/crlite-part-2-end-to-end-design/ The file "crlite.filter" contains all revocation information.

Issue with Arkenfox applied: With Arkenfox applied the lists never get downloaded.

A clean install of Firefox is not affected by the issue

Tested with a clean Firefox 122.0.1 install, no user.js and only two about:config adjustements applied:

In this case CRLite files are downloaded successfully (took a few minutes and is reproducable): image Same behavior is expected with Arkenfox, since CRLite is enabled per default by Arkenfox. With Arkenfox the files are missing after waiting for several hours.

🟥 https://github.com/arkenfox/user.js/wiki/5.2-Troubleshooting

🟪 REQUIRED INFO

Thorin-Oakenpants commented 7 months ago

So my FF has it no issues, I think it just takes time... I'm just spitballing here

IDK if that means anything, and I didn't test much, but on a new FF (portable, I just rename the profile and it creates a new on on demand), I added AF and sure, nothing downloaded in the first 5 minutes.

My main AF (also portable) does have it (edit: not going to try and explain why a non AF test from OP went and got it immediately - maybe setting from user.js doesn't have the same listeners as about:config because FF is still booting)

Give it a day and then report back

Thorin-Oakenpants commented 7 months ago

That's interesting - LW (3, true) doesn't have anything and it's been installed for months (but I almost never open it)

Nightly (installed) has files (3, true) - dated almost 24 hrs old Beta (installed) has files (3, false) - dated 25th January, maybe they flipped it on then off?

FF122 (basically nillas in a test suite - all portables) - flipped to (3 default, true) - downloaded within a few minutes

Hmmmm

Thorin-Oakenpants commented 7 months ago

OK, solved it

/* 2616: remove special permissions for certain mozilla domains [FF35+]
 * [1] resource://app/defaults/permissions ***/
user_pref("permissions.manager.defaultsUrl", "");

the default for this is resource://app/defaults/permissions which if you load it is this

# <snip> ...
# See PermissionManager.cpp for more...

# UITour
# Bug 1557153: www.mozilla.org gets a special workaround in UITourChild.sys.mjs
# Bug 1837407: support.mozilla.org gets a special workaround for similar reasons.
origin  uitour  1   https://www.mozilla.org
origin  uitour  1   https://support.mozilla.org
origin  uitour  1   about:home
origin  uitour  1   about:newtab

# XPInstall
origin  install 1   https://addons.mozilla.org

# Remote troubleshooting
origin  remote-troubleshooting  1   https://support.mozilla.org

# autoplay video/audio
origin  autoplay-media  1   about:welcome

in a new profile on FF122, I added AF with one change, I comments out that pref. Worked like a charm - although this doesn't fully make sense to me how any of those relate to crlite. Also once crlite is established, it is updated.

@brokoler see if you can reproduce my fix

brokoler commented 7 months ago

@Thorin-Oakenpants Thanks for helping! After my recent testings it's not related to user_pref("permissions.manager.defaultsUrl", "");

I further checked on this and my guess is, that the CRLite files are installed via Push Services. It seems like the Mozilla Push Server contacts the client, because of that the installation seems delayed by minutes or hours.

So following value is required (already enabled in AF per default): user_pref("dom.push.enabled", true);

It was enabled in my setup but took long. With an install where I disabled Push Services it definitely never came through. Still in testing phase, but I'm mostly sure about it and logged the network connectivity via GlassWire where "autopush.prod.mozaws.net" was contacted when my files FINALLY arrived :)

So nothing to change on AF side, just a reminder how important dom.push.enabled is.

brokoler commented 7 months ago

Can confirm it worked multiple times now. Only with Push Services enabled, they are mandatory to receive CRLite files.

brokoler commented 7 months ago

Very vague description by Mozilla (Does mention a Remote Server pushes updates to online Firefox Clients): https://blog.mozilla.org/security/2020/12/01/crlite-part-4-infrastructure-design/

grafik

Thorin-Oakenpants commented 7 months ago

great detective work @brokoler ... here's your cake 🍰 :)

I will so something in the user.js - thanks

Thorin-Oakenpants commented 7 months ago

when I do the next PR

/* 7019: disable Push Notifications [FF44+]
 * [WHY] Website "push" requires subscription, and the API itself is required for CRLite (1224)
 * [NOTE] To remove all subscriptions, reset "dom.push.userAgentID"
 * [1] https://support.mozilla.org/kb/push-notifications-firefox ***/
   // user_pref("dom.push.enabled", false);
Thorin-Oakenpants commented 7 months ago

dom.push.enabled is true in LW ... but I did see a bunch of maybe related errors in the console for remote-settings/ .. so my best guess is this is caused by a patch they did trying to make "Firefox silent" (see the black vs white false dichotomy in #1807 ) - if this is the case, just another example of perceived privacy gains but actually achieving security losses

prettyv commented 7 months ago

I also believe this has to be related to some Remote Settings related changes there, as despite having dom.push.enabled set to false here (I'll re-enable this, just an oversight on my part), the expected CRLite files in the profile's security_state are up-to-date having been updated an hour ago. I.e. the files are fetched from Remote Settings by regular polling (see the event handler here) just fine, not sure where the additional push message is handled in the code specifically after a quick search.

So as I understand it this only means updates could reach Firefox faster with enabled push services, but they aren't strictly required. The added comment "and the API itself is required for CRLite" is thus at least misleading I think and should be either softened - indicating faster CRLite data updates - or removed again.

Thorin-Oakenpants commented 7 months ago

The polling is 24 hrs and I linked to it in https://github.com/arkenfox/user.js/issues/1811#issuecomment-1951201076 - so yes, Remote Services is used. My best guess is the change in prefs is picked up and uses push to get started, else ?? it then manifests within 24 hrs (depends when your next poll is)? right ??? If someone wants to test that and confirm, then I can amend my proposed change

PS: no, I don't want to remove it :)

brokoler commented 7 months ago

I will test how the CRLite updates look in real with following setting and give feedback here: user_pref("dom.push.enabled", false);

Personal opinion (Privacy related)

user_pref("dom.push.enabled", true); might be a privacy concern, since the browser establishs a persistent connection to Amazon AWS services. Besides CRLite updates, what else does someone really need from Push Services? Most websites don't use push and the functional gain of push messages is minimal for a webbrowser (compared to a smartphone, where it's mostly mandatory).

Especially when you think about the latest leaks of government documents that Push Services spy on users on Apple and Android Smartphones, this might be the same with Firefox Push Services enabled: https://www.reuters.com/technology/cybersecurity/governments-spying-apple-google-users-through-push-notifications-us-senator-2023-12-06/

You have to decide yourself if the security gain by faster CRLite updates is worth potential privacy issues. For me CRLite is definitely required, I will evaluate if and how often files are updated with Push Services disabled.

brokoler commented 7 months ago

Opened a feature request on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1880888 Hopefully CRLite will work more reliable in future with disabled Push Services.

Update from my testings

All installations with "dom.push.enabled = false" did not download CRLite files, the folder "security_state" is empty. I'm mostly sure the trigger value of 24 hours is also related to Remote Settings and not used when Push Services are disabled.

Thorin-Oakenpants commented 6 months ago

https://codeberg.org/librewolf/issues/issues/1794

two weeks .. dead silence ... nobody's home!!

so https://github.com/arkenfox/user.js/pull/1816/commits/e037014a56ed22a7de39ebef6efe9dfe0c325549 is the commit

speak up if anyone is unhappy with how I framed it

brokoler commented 6 months ago

@Thorin-Oakenpants Guess it will never work with Librewolf, since they block the hardcoded URL "firefox.settings.services.mozilla.com". It's a philosophy thing I guess.

Also there is a testing website, with a revoked certificate, to check if CRLite works: https://digicert-tls-ecc-p384-root-g5-revoked.chain-demos.digicert.com/ (Make sure OCSP checking is disabled when you want to test if CRLite works)

With the settings Arkenfox is using it works fine!

brokoler commented 6 months ago

@Thorin-Oakenpants some more updates about my findings.

You can download CRLite files with dom.push.enabled = false In this case services.settings.poll_interval = 1 is required (all other values didn't work for me).

These values combined successfully download and update CRLite files with the AWS push connection being disabled. With these parameters the download is triggered by the Firefox client only, also the files are downloaded immediately after first startup (takes around 1 minute).

Thorin-Oakenpants commented 6 months ago

Thanks

In this case services.settings.poll_interval = 1 is required (all other values didn't work for me).

yeah .. we're not going to do polling every 1 second and I wouldn't expect anyone else to either. So I think the user.js edit is perfectly correct given a few assumptions

fossfreak commented 6 months ago

dom.push.enabled is true in LW ... but I did see a bunch of maybe related errors in the console for remote-settings/ .. so my best guess is this is caused by a patch they did trying to make "Firefox silent"

I was able to override this behaviour in LW by changing the setting services.settings.server to https://firefox.settings.services.mozilla.com/v1

In WF the setting wasn't present. After adding it the CRLite files populated after a few minutes, just like in FF stable.