Re: How to handle updates to mozilla-rootcerts?

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%joyent.com@localhost> writes:

> * On 2018-04-18 at 23:46 BST, Greg Troxel wrote:
>
>>   The idea that you install some random package and as a side effect the
>>   set of configured system trust anchors changes is not ok.  So we
>>   either need some explicit user choice to let mozilla-rootcerts control
>>   system trust anchors, or a rule that it can't be a dependency.
>
> Could someone explain why this isn't ok?  I'll admit I don't really
> understand why people have issues with this.  My vague understanding
> is that some folks don't trust all of the CAs bundled in this package
> and go through and weed out the ones they don't like, but then what do
> they do about domains that are signed by that CA?

This is definitely messy.

The entire scheme of public CAs is basically broken; there is a a very
big list of public CAs, and if a certificate is signed by any of them,
it is believed.  There have been instances of untrustworthy CAs.  It is
highly likely that at least one CA currently in the list is currently
compromised.  Reactions range from not configuring the list to just
accepting the whole list and choosing not to worry.  In addition,
there's a parallel universe of CAs for the US government, where they
more or less trust their own but not the mozilla set, and the USG CAs
aren't in the mozilla set.

Browsers have a preconfigured set of CAs, and this is usually close to
the mozilla set.  Operating systems are far less uniform.

So far, NetBSD has chosen not to install trust anchors in the system
openssl.  You can view this as a cop-out for not dealing, or taking the
high road and separating policy from mechanism, but that's how it is
today.  Other systems seem to have varying approaches, and I'm not clear
on exactly which ones take which paths.  To avoid getting into
validating CAs, it seems an OS should choose between 1) none and 2) the
mozilla list.

As for weeding out CAs, I don't really know how people typically choose.
The issue is not so much domains signed by untrusted CAs, as that having
an untrusted CA in the trust anchor set means that if a cert for some
other domain is presented, it will be believed.


With pkgsrc, we have multiple questions:

  - do we install trust anchors in the system openssl?
    - if the user explicitly requests this?
    - as a side effect of building or installing something else?

  - do we install trust anchors in pkgsrc openssl?
    - (explicitly)?
    - (side effect)?

From a security point of view, if the base OS chooses not to install
trust anchors, and I build some python module, and that results in the
system being reconfigured to have 200 trust acnhors, that seems crazy.
While you can argue that the base OS decision was wrong (and I'm
avoiding that debate as we are talking about pkgsrc's response to a
given situation), I don't see how changing base policy as an unexpected
side effect can be reasonable.

> If it's only a small minority of people who do this, then it seems
> unfair to ruin everyone else's experience, when those who do have such
> concerns are likely technical enough to implement a post-install way
> of doing the pruning or setting a build flag or whatever without
> affecting users who just want HTTPS to work out of the box.

Part of the problem is the definition of "work".   On one hand there is
"I asked for these bits; did I get them".  On the other is "can I
believe this".

Overall, I feel really uncomfortable for pkgsrc to be making a different
security choice than the base OS, and switching the config.

Stepping back, I think part of the issue is that we are conflating
changing the base system configuration (or the pkgsrc openssl
configuration for random uses of pkgsrc openssl), whereas the real
requirement, and what I think you are getting at, is for use of https
download by the pkgsrc infrastructure to function (get the bits via a
fetch over https).   We are not all that concerned about the
authentication value of https, given our checksums.

So perhaps a way to resolve the "https fetch" issue without stepping
into "are these CAs trustworthy" issue is to someone pass a "use this
list of trust ancnors" flag to fetches from pkgsrc.  Another option is
wget's --no-check-certificate, but that seems like a bigger hole that is
needed.