Open Bug 1757541 Opened 6 months ago Updated 5 months ago

Firefox add-ons certificate interaction with RHEL crypto policy (some add-ons breaking with FUTURE policy)

Categories

(Toolkit :: Add-ons Manager, enhancement, P3)

Firefox 91
enhancement

Tracking

()

People

(Reporter: alex.47260, Unassigned)

References

Details

Steps to reproduce:

Running RHEL 8.5 with the aligned version of Firefox (initially 91.5 then 91.6), I noticed there is something between Firefox add-ons and FUTURE crypto policies on RHEL.

Eg.

  • with crypto policies set to DEFAULT, I can install extensions such as Privacy Badger or Disconnect, and these will still work after I changed the policy to FUTURE and rebooted the computer ;
  • however, with these policies set to FUTURE, a number of add-ons can't be added and there is a red box saying the add-on couldn't be added because it is corrupt - this happens to add-ons such as Ghostery, Cookies & HTTP header, HTTPS everywhere
  • back to DEFAULT, the same add-ons that were presented as corrupt can be added again to Firefox, and seem to work fine.

Actual results:

Covered in the above section, are steps and results are a bit intermingled there.

Expected results:

This ia a request to ask Firefox team to have a look please at the relation between Firefox add-ons (signatures?) and RHEL crypto policies.

In the RHEL hardening guide online at the below URL, the content of DEFAULT and FUTURE policies is described
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

DEFAULT : The default system-wide cryptographic policy level offers secure settings for current threat models. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 2048 bits long.

FUTURE : A conservative security level that is believed to withstand any near-term future attacks. This level does not allow the use of SHA-1 in signature algorithms. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 3072 bits long.

Many thanks and kind regards,

Alex

The Bugbug bot thinks this bug should belong to the 'Toolkit::Add-ons Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit

Many thanks for looking at this ticket and for re-direction!

Hello,

I’m from QA and I’m attempting to reproduce the issue in order to confirm it.

From reading the bug description, it seems that crypto policies are something available on RHEL only and I’m currently running Ubuntu 16.04 LTS where if I run update-crypto-policies –show, it will throw a “command not found” error in the terminal. I have no possibility of updating it or installing a different OS due to company policies.

Is there a way to reproduce this on Ubuntu 16.04 LTS or Windows 10? Thank you !

I will also try and involve the developer/s in the chance they can help with confirming this.

Flags: needinfo?(alex.47260)
Flags: needinfo?(tomica)

Hello,

@Alex Cornestean : not sure if you may or not use VMWare or Oracle Virtualbox in your company, because I guess it should be possible to reproduce the issue on Ubuntu 16.04 LTS or Windows 10 with a VM, where the behavior can be checked with a standard installation of RHEL 8.5 iso in the VM.

On a side note, the issue is identified thanks to Red Hat but maybe it's revealing something about some add-ons certificates / signature?

In the man page of update-crypto-policies, it is written that this package interacts with NSS :
https://www.mankier.com/8/update-crypto-policies#Application_Support

it looks like that Firefox also interacts with NSS :
https://firefox-source-docs.mozilla.org/security/nss/legacy/pkcs11_functions/index.html

Then, the package update-crypto-policies is related to RHEL, but there is a package that may be similar on Fedora Linux distributions too:
https://packages.fedoraproject.org/pkgs/crypto-policies/crypto-policies/

Trying to assist in this topic as much as possible but not being a specialist of these matters. Is there anything else I could help with - eg. provide some additional information on the system I use, or make a video recording with the full series of events?

Please feel free to suggest what I could do to facilitate the verification.

Kind regards,

Alex

Flags: needinfo?(alex.47260)

Hello Alex,

Following your advice, I’ve installed Virtualbox and RHEL8.5 on it.

Unfortunately, now I’m running into some issues. It either freezes during boot for some reason and sometimes after logging in. I’ll try and sort out this ASAP and attempt to reproduce the issue.

Thank you for your patience !

Hi Alex,

No worries at all and btw, some people prefer VMware so you may try with this software as well, just in case - although I have been using VirtualBox on both Ubuntu & RHEL, and it worked fine. And again, happy to help if there is anything I can do here.

Speak soon,

Alex

Hey @Alex

I installed VMWare and finally managed to get RHEL8.5 running.

As to the bug itself, I’ve tested several Firefox versions including the latest Release, ESR 91.7.0, ESR 91.6.1, ESR 91.6.0 and ESR 91.2.0 which I installed myself from https://archive.mozilla.org/pub/firefox/releases/ AND I’ve also tested the ESR 91.2.0 which came bundled with RHEL8.5.

As for the tests, with the crypto policies set to DEFAULT, all add-ons could be installed and these continued to work even after changing the policy to FUTURE, on both the browsers I manually installed and on the RHEL bundled one. For reference, I used Privacy Badger and Disconnect for this test.

Now with the policy set to FUTURE, add-ons could still be installed on the browsers I manually installed but NOT on the RHEL bundled one which threw the corrupted red error on the add-on detail page in AMO. For reference, I used Ghostery and HTTPS Everywhere for this test.

Changing the policy back to DEFAULT, allowed me to install addons unhindered on all the browsers.

So it seems, the only affected browsers are the ones which come bundled with the OS and not the ones a user might manually install afterwards.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Hi @Alex,

Many thanks for the response and in-depth review!

So, if I understand correctly, as the issue doesn't happen with Firefox 91.6 or other versions that you have manually installed on your RHEL 8.5 VM, but only for a certain number of add-ons with the version of Firefox 91.6 in the RHEL bundle, is it a topic to be transferred to/handled by Red Hat then?

Btw, as I understand there are some very urgent topics on-going with Firefox, I won't post about it today or tomorrow on a Red Hat forum, but could you please suggest what the next step should be please?

Many thanks & kind regards,

Alex

Hello Alex,

Yes, you understood correctly. The issue happens with the browser that comes bundled with the OS and I would presume it affects all add-ons, though I only tested the ones that I mentioned.
Browser versions manually installed by the user are not affected as per what I observed during testing.

As for the issue being forwarded to Red Hat, I’m not quite sure you should do that yet, as I’d suggest to wait for one of our developers to get involved and have a more in-depth look at the issue.
Since the issue was confirmed and marked as New, developer input should arrive soon.

In the meantime, if you need the policy to be set to FUTURE and use/install certain add-ons, I’d most likely suggest you manually install a browser version of choice and use that. Of course, only if it suits your needs.

From a quick look to the comments in this issue, it looks like it may likely be a duplicate of Bug 1682613.

I'm going to link them together as "See also" for now (to be eventually closed as a duplicate of Bug 1682613 once confirmed that the two bugzilla issues are exact duplicate of each other as it seems, e.g. as part of our next triage meeting).

Flags: needinfo?(tomica)
See Also: → 1682613

The severity field is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mixedpuppy)
Severity: -- → N/A
Type: defect → enhancement
Flags: needinfo?(mixedpuppy)
Priority: -- → P3

Hi everyone,

Many thanks for your follow up on this thread!

Just wondering, with regards to the last four messages, would this issue be the same one as Bug 1682613 or is it something different (as suggested by the fact that the ticket id 1682613 is categorized as a 'bug' while this current issue is an 'enhancement?

Kind regards,

Alex

You need to log in before you can comment on or make changes to this bug.