1637807 - allow webextensions to set "security.osclientcerts.autoload" so users can use client certificates from the OS

Status: RESOLVED FIXED

(WebExtensions :: General, enhancement, P3)

Description

[Dana Keeler (she/her) [:keeler]]

(There's some background at https://blog.mozilla.org/security/2020/04/14/expanding-client-certificates-in-firefox-75/)

Some users need to be able to use client certificates that are stored on smart cards or in OS certificate storage. There are some webextensions that enable this by loading 3rd-party PKCS#11 modules. We've developed our own module for Windows and macOS that should provide the same functionality but with better performance and fewer stability issues. It would be great if these webextensions could set the pref that enables this module ("security.osclientcerts.autoload" to true) instead of loading these modules.

Comment 1

[Tomislav Jovanovic :zombie]

Dana, our understanding is this will be the default configuration in a few releases, will this flag be useful after that.

Comment 2

[Dana Keeler (she/her) [:keeler]]

We're not planning on ever enabling this by default for everyone, so this flag will be useful for users that use things like https://github.com/open-eid/firefox-pkcs11-loader to configure Firefox to authenticate to government sites, etc.

Comment 3

[Shane Caraveo (:mixedpuppy)]

I'm slightly confused by why this is being requested. Must a user both install our extension and flip the pref? Or does flipping the pref obviate the need for the extension (except to flip the pref)? Is the pref generally applicable for all pkcs11 extensions? Is the pref going to exist/be necessary for the foreseeable future? Does the pref have valid use without pkcs11?

I see that enterprise policies already allow setting this value, so I'm guessing that

a) it does have applicability without pkcs11
b) it is a long lived pref

If that is the case, I'd suggest it be placed in privacy.services or browserSettings. Both those would require adding a new permission to the addon. If it is only applicable in combination with pkcs11, then it would be fine to add to that namespace.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/privacy
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browserSettings

Comment 4

[Dana Keeler (she/her) [:keeler]]

I'm requesting this because currently users who need to use client authentication certificates to access certain sites to e.g. pay their taxes tend to install extensions that use the existing pkcs11 API to load 3rd-party PKCS#11 modules into Firefox. These modules tend to cause stability problems for Firefox. We wrote our own PKCS#11 module that should provide the same functionality to users but with better performance and stability. Currently this module is disabled by default, unless that pref is flipped. Not every Firefox user needs this functionality, so we're going to leave the module disabled by default for the foreseeable future. I would like to make it so that extensions can enable this pref so that if these extensions start enabling the pref, current users will automatically start using the new module when they update.

To answer your specific questions, the user may either flip the pref themselves if they know about it or install the extension, which would do it for them.
The pref is not generally applicable to all pkcs11 extensions. Flipping the pref causes Firefox to load a particular PKCS#11 module that we wrote ("osclientcerts") that we're hoping will generally replace all other pkcs11 modules.
The pref will exist and is necessary for the foreseeable future.

See also the blog post linked in comment 0 for more background, and let me know if I can clarify anything about why this is important. Thanks!

Comment 5

[Shane Caraveo (:mixedpuppy)]

Ok, so if I understand correctly: we bundle a pkcs11 module and turning on this pref loads that module.

I don't think I'd want to expose an api for that because it is very specific and not something any other addon would use. It could be done with a mozilla signed addon using an experimental api to flip the pref, but why not expose that in about:preferences?

Comment 6

[Dana Keeler (she/her) [:keeler]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #5)

Ok, so if I understand correctly: we bundle a pkcs11 module and turning on this pref loads that module.

Yep - that's it.

I don't think I'd want to expose an api for that because it is very specific and not something any other addon would use. It could be done with a mozilla signed addon using an experimental api to flip the pref, but why not expose that in about:preferences?

This is not specific to that particular add-on. Eventually our goal is that any add-on that would use the pkcs11 API to load a PKCS#11 module will set this preference instead. The benefit of doing this is that anyone who already has any of these add-ons installed will automatically start using the new module instead of 3rd-party modules. Also, the instructions users follow to enable their government/corporate smart-cards (e.g. Spain, Estonia, Facebook, Boeing, etc.) don't have to change. This means that more users will have a better experience without them having to each individually go into about:preferences and modify a setting. This is not to say I disagree that we should expose this in about:preferences (I think that's a good idea), but that this API would be an effective way of improving the experience of many users at once. Maybe think of it as a better version of the current pkcs11 API, which, after all, only exists because the current UI in about:preferences for adding PKCS#11 modules is hard to find and use, whereas simply installing an add-on that does it automatically is a much better user experience.

Comment 7

[Shane Caraveo (:mixedpuppy)]

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #6)

(In reply to Shane Caraveo (:mixedpuppy) from comment #5)

Ok, so if I understand correctly: we bundle a pkcs11 module and turning on this pref loads that module.

Yep - that's it.

I don't think I'd want to expose an api for that because it is very specific and not something any other addon would use. It could be done with a mozilla signed addon using an experimental api to flip the pref, but why not expose that in about:preferences?

This is not specific to that particular add-on. Eventually our goal is that any add-on that would use the pkcs11 API to load a PKCS#11 module will set this preference instead. The benefit of doing this is that anyone who already has any of these add-ons installed will automatically start using the new module instead of 3rd-party modules.

That depends on all those other addons being updated and choosing to prefer our module over their own. Do we have some indication that will happen? If we already bundle, ours is better, and there are no extra features a 3rd party might offer that improves on what we bundle, we should be thinking towards a better solution rather than perpetuating this api. From what I understand at this point, I would suggest the following:

1. if a 3rd party module is configured to load, replace that with our own

• this benefits users immediately without addon updates/etc.

2. always flip the pref and load our module when a 3rd party extension tries to load their module

• pkcs11.installModule turns on the pref, uninstallModule turns it off ??, isModuleInstalled returns pref value
• pkcs11.getModuleSlots communicates only with our implementation (name param gets ignored)
• existing instructions for users continue to work
• existing 3rd party addons need no update, do not need to decide to switch to our module

3. add about:preferences to turn on support without any addon
4. notify primary pkcs11 documentation locations to update their documentation for users, point to about:preferences
5. deprecate most of the pkcs11 api (getModuleSlots seems like it may still be useful otherwise?), we could lengthen the deprecation period

Comment 8

[Dana Keeler (she/her) [:keeler]]

Thanks for the feedback. I'll discuss this with the team and see how we want to proceed.

Comment 9

[Shane Caraveo (:mixedpuppy)]

Dana and I just chatted which quickly resolved this. We'll go ahead with a way to turn on the mozilla implementation for now. I'll drop some pointers for implementation and Dana will write up a patch.

Comment 10

[Shane Caraveo (:mixedpuppy)]

Followup on comment 9.

The ultimate goal if possible is to have firefox natively support pkcs11 so that 3rd party modules are no longer necessary. This is how other browsers work. Due to the wide variety of software/hardware supported we want to have time for our module to be used through enabling via an addon prior to switching fully over to the native implementation. Perhaps by next ESR?

Comment 11

[Shane Caraveo (:mixedpuppy)]

Some guidance for Dana; this is a dump of information, while this is one of the simpler apis to add, there is some familiarity that has to be built. Hopefully this is enough to start, please slack/chat me with any questions at any point.

Given a pref that will cause the module to load or unload, and assuming we want to "reset" the value if the extension is uninstalled, we'd likely want a settings value for this. I'm not sure of a good name in the api, so this, autoload, is just an example name and we could use something else.

API: browser.pkcs11.autoload.set({enabled: true});

It may look a touch weird, but it's the standard api form for settings throughout webextensions. The settings api also provides a get() function, so the pref value can be queried.

One problem that may be run into with the existing APIs is what you should return in the isModuleInstalled and getModuleSlots API calls (see ext-pkcs11.js linked below). It may be nothing, or you may want to have something returned for the builtin module. Should an extension be able to query that the builtin module is actually loaded?

You'll need to modify a couple files and add a test. The first is the api schema[1]. Here you'll want to essentially copy how we do a setting[2] and put it into a new "properties" section in the api schema.

In the api implementation[3] you'll need to add the preferences setting similar to how it is done in browserSettings[4][5]. You'll also need to throw an error if this setting is used on an unsupported platform[7].

A new test should be added[6], you might refer to the browserSettings tests[8] though they may be a bit more convoluted than necessary if you haven't looked at extension tests much.

[1] https://searchfox.org/mozilla-central/source/browser/components/extensions/schemas/pkcs11.json
[2] https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/toolkit/components/extensions/schemas/browser_settings.json#40-44
[3] https://searchfox.org/mozilla-central/source/browser/components/extensions/parent/ext-pkcs11.js
[4] https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/toolkit/components/extensions/parent/ext-browserSettings.js#39-50
[5] https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/toolkit/components/extensions/parent/ext-browserSettings.js#193-200
[6] https://searchfox.org/mozilla-central/source/browser/components/extensions/test/xpcshell/test_ext_pkcs11_management.js
[7] https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/toolkit/components/extensions/parent/ext-browserSettings.js#211-226
[8] https://searchfox.org/mozilla-central/source/toolkit/components/extensions/test/xpcshell/test_ext_browserSettings.js

Comment 12

[Dana Keeler (she/her) [:keeler]]

Attachment: Bug 1637807 - add browser.pkcs11.autoload API to allow webextensions to enable osclientcerts r?mixedpuppy

This patch adds the setting browser.pkcs11.autoload that can be set to true
to cause Firefox to load the built-in "osclientcerts" module, which uses OS APIs to
provide access to client certificates. This means that webextensions can opt to
use a module developed and supported by Mozilla for TLS client authentication
rather than 3rd party modules that have historically caused stability and
performance issues for users.

This API is currently only available on Windows and macOS.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a34e77d6c3bf
add browser.pkcs11.autoload API to allow webextensions to enable osclientcerts r=mixedpuppy

Comment 14

[Noemi Erli[:noemi_erli]]

Backed out changeset a34e77d6c3bf (Bug 1637807) for crashes @InvalidArrayIndex_CRASH CLOSED TREE

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&searchStr=windows%2C10%2Cx64%2Cshippable%2Copt%2Cmochitests%2Ctest-windows10-64-shippable%2Fopt-mochitest-browser-chrome-e10s-3%2Cm%28bc3%29&revision=a34e77d6c3bf775acf9ad987e215038fb2edab72&selectedTaskRun=IK1WXOARSmy28NkWGE8CDg-0

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=305723962&repo=autoland&lineNumber=4552

Backout: https://hg.mozilla.org/integration/autoland/rev/655e47d9e0b59cf3c71bbe0c067eb6891cd170b3

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/27aa570a7970
add browser.pkcs11.autoload API to allow webextensions to enable osclientcerts r=mixedpuppy CLOSED TREE

Comment 16

[Noemi Erli[:noemi_erli]]

Relanded since this wasn't the culprit for our issue. Sorry about that

Comment 17

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/27aa570a7970

Comment 18

[Philipp Kewisch [:Fallen][☁️📆]]

Dana let us know this is being reverted in bug 1649518, so we don't need documentation on this after all.