Open Bug 1591269 (osclientcerts) Opened 6 years ago Updated 1 year ago

[meta] osclientcerts tracking bug

Categories

(Core :: Security: PSM, task, P3)

task

Tracking

()

People

(Reporter: keeler, Unassigned)

References

(Depends on 3 open bugs)

Details

(Keywords: meta, Whiteboard: [psm-tracking])

Attachments

(1 obsolete file)

This bug tracks the implementation of the osclientcerts PKCS#11 module that will enable Firefox to use client certificates from the OS.

Depends on: 1591271
Keywords: meta
Depends on: 1592111
Depends on: 1597525

Are there plans for Unix?

To my knowledge, there's no stable mechanism to store certificates using a TPM/TrustZone on Linux or the BSDs. Gnome-Keyring can probably be hacked on to do it via trousers [0], but arguably since that produces a PKCS#11 module, it could just be plugged straight into Firefox and "be" this implementation instead of the osclientcerts rust library... but trousers is not actively maintained, and I'm not sure of anything else state-of-the-art in the *nix world for this.

Most distributions install client certs directly into system NSS, which is then used by Firefox, which makes it de facto the OS Client Cert store already.

[0] https://github.com/srajiv/trousers

Depends on: 1602593
Depends on: 1610644
Depends on: 1616330
Alias: osclientcerts
Depends on: 1619817

I had opened https://bugzilla.mozilla.org/show_bug.cgi?id=1624317 which is now closed WONTFIX due to the presence of this osclientcerts plan.

I hope that the foundation does decide to address this soon. It's been outstanding for a long time, and I worry that it provides a real attack chain opportunity (infect a "known good" page where users SHOULD unlock their stored certificates, then redirect them somewhere else where they should NOT, but as the one-time-per-session unlock has already been performed, their certificates can then be [ab]used without a password prompt).

I see that it is currently dependent on a bug relating to the level of debugging available from the current interface to Windows OS client certificate storage.
I wonder that waiting on more-perfect diagnostic information from that module, while retaining the current too-low granularity of control over access to security-critical assets (certificate private key use) maybe isn't the right balance?

thank you.

Depends on: 1631124
Depends on: 1637404
Depends on: 1645917
Depends on: 1648855
Depends on: 1649518
Depends on: 1654117
Depends on: 1658042
Depends on: 1629002
Depends on: 1661447
Depends on: 1662636
Depends on: 1666878
Depends on: 1666879
Depends on: 1662247
Blocks: 1674410
Depends on: 1669414
Depends on: 1682596
Depends on: 1693375
No longer depends on: 1694200
Depends on: 1690278
Depends on: 1696997
Depends on: 1695974
Depends on: 1699882
Depends on: 1701983
Depends on: 1709848
Depends on: 1711154
Depends on: 1712848
Depends on: 1715325
Blocks: 1722445
Depends on: 1725025

In about:config, security.osclientcerts.autoload=true by default (at least Firefox 97). But some CA is incredibility, such as CNNIC ROOT, which had been untrust by most browsers for a long time, but it still in Windows Certmanagement, so if any goverment malware install it, and any website use certificate issue by CNNIC, it will store into Firefox certificate store, gov could use it to MITM, it's very dangerous!

So I hope security.osclientcerts.autoload = false by default.

osclientcerts doesn't affect the trust settings of root certificates.

Depends on: 1761262
Depends on: 1771274
Depends on: 1778997
Severity: normal → S3
Depends on: 1722306
Depends on: 1828968
Attachment #9386376 - Attachment is obsolete: true
Depends on: 1937808
Depends on: 1962280
Depends on: 1964125
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: