Here's a mozilla bug which tracks fixing the issue in the Mozilla PSM code: https://bugzilla.mozilla.org/show_bug.cgi?id=880269

Created attachment 81414 [details] [review]
trust: Use NSS's name for default trust token

Several NSS using applications check the token label for the default
builtin certificates before using trust from that store.

Sicne p11-kit-trust.so is supposed to (also) be a drop in replacement
for libnssckbi.so, use the same token name.

NSS likes tokens to have unique labels. However this is a replacement
for the libnssckbi.so tokens, and thus using the same token and
certificate labels is not a surprise.

The attached patch changes only the "Default Trust" token to the NSS label of  "Builtin Object Token". The certificates/trust on this token are the ones installed by rpms, not the ones configured by the system administrator.

This matches the intents of applications that check the token label (like Firefox's extension install code): that the certificate and trust policy have come from the builtin set and not a configured source.

With this patch we allow p11-kit-trust.so to be a drop in replacement for libnssckbi.so as it was designed to be.

I still think that the way this check is done in Firefox and other apps is dubious (see my comments on mozilla bug).

I think this is a bad idea. The issue that this was supposed to deal with looks like it will be resolved upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=880269#c5 (Dan Veditz is the mozilla security guy, If he agrees, then it's likely to happen).

Let's not start off on the wrong foot here because of this issue. There is already a way to determine if a module is a 'built-ins' module without hacking up the token name.

bob

(In reply to comment #4)
> I think this is a bad idea. The issue that this was supposed to deal with
> looks like it will be resolved upstream:
> https://bugzilla.mozilla.org/show_bug.cgi?id=880269#c5 (Dan Veditz is the
> mozilla security guy, If he agrees, then it's likely to happen).

Well there are lots more upstreams. This string is found in many projects.

> Let's not start off on the wrong foot here because of this issue. There is
> already a way to determine if a module is a 'built-ins' module without
> hacking up the token name.

I won't be pushing this into p11-kit upstream, based on the discussion here and on IRC.

However if a downstream OS needs to have the p11-kit-trust module be a compatible drop-in replacement for libnssckbi.so (eg: to use in a point version of a stable Linux distribution), this patch can be used to accomplish that.

I would like to reopen this issue, and request that we create a finer grainer solution than the one originally suggested.

In the meantime, the situation has become worse in Fedora land.

In comment 4, Bob assumed that in order to solve the problems, it would be sufficient to distinguish between CAs stored in a 'built-ins' module, CAs that aren't.

That's no longer sufficient for the most recent issue we're seeing.

Mozilla has decided to impose additional constraints on the root CAs that they ship with Firefox. For example, for certificates issued after a certain date, they require that a subject-alt-name is present, and they no longer accept the domain name in the subject CN as sufficient.

On Fedora, where admin installed private CAs are provided to Firefox as part of our p11-kit-trust module, Firefox imposes those same constraints on the enterprise issued certificates, too.

As a result, Fedora Firefox rejects certificates issued by private CA deployments, see https://bugzilla.redhat.com/show_bug.cgi?id=1400293#c9

I've reported the issue to Mozilla, but the developer thinks the issue needs to be fixed outside of Firefox, because Firefox itself is working correctly, it's only because of our modifications to the trust module that things are failing:
https://bugzilla.mozilla.org/show_bug.cgi?id=1324096

There is an additional known bug. HPKP (http public key pinning) in Firefox is broken on Fedora. You can find the detailed explanation why it's broken here: https://bugzilla.redhat.com/show_bug.cgi?id=1207335

The situation is worse here, because enabling pinning for sites from private CAs, which might be use for MITM boxes, could lock out users from accessing the sites again, when roaming across networks with portable devices across networks.

So, despite the fact that Mozilla has recently changed their code to no longer check the token name for an exact match, but rather use the "has builtins" to identify the token
 ( https://hg.mozilla.org/mozilla-central/rev/50a6f462a97c )
that still doesn't help us.

We need a solution that solves both of the following:

(a) only the root CAs that Mozilla ships are considered built-in status,
    to ensure
    (1) only those will be allowed for public web pinning,
    and
    (2) only those will be enforced to comply with the additional 
        constraints that Mozilla wants on the public web

(b) all CAs installed by a local deployment, that isn't part of the
    public web, should be on a module that doesn't match 
    Mozilla's built-in properties


My older idea for a solution was:
- introduce a third category into p11-kit-trust, in addition to 
  the already existing "system trust" and "default trust".
- name that new third category "builtin object module",
  with the identical name of the old libnssckbi.so module
- change p11-kit-trust, so that it assigns the CAs to the new
  category based on the input filename,
  e.g. if a file scanned by p11-kit-trust is named with a prefix like
    mozilla-nss-*
  then it gets into the "builtin object module" category,
  and other ones go into the categories as before
  This approach would have the benefit, that we don't change the behavior
  of deployments, that are already installing private CAs into the /usr
  location.
  (Because we probably cannot be certain that Stef's ealier simply assumption
  is correct, not all deployments might install local CAs into /etc,
  some might use rpm packages to install local CAs into /usr).

But with the new change made by Mozilla, I'm no longer sure this solution is sufficient.

I believe that locally installed CAs shouldn't be in a module that has the "is builtin module" status?

I suggest that we use a fresh bug for the new solution.

Because the discussion in this bug was focused on changing the token name, but because we seem to require a more advanced solution, I'll flip this bug back to WONTFIX.

I have filed this new bug: 99453