Re: [PATCH] HTTPS/TLS CA certificates in base

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 20 Aug 2023 05:43:23 +0200
> From: Jan Danielsson <jan.m.danielsson%gmail.com@localhost>
> 
>     My objection in the past has been along the line of:  If an 
> organization is not willing to keep a CA bundle up-to-date for a user, 
> then it should not dump a CA bundle that may grow stale onto their 
> system either.  But that's more of a "pick a well-trusted CA bundle, and 
> provide a mirror of it that people can synchronize from -- and keep it 
> up-to-date." argument, rather than a "don't do it" argument.

Here's what I wrote in the original message:

> > Some objections in the past included:
> > [...]
> > - We can't do this until we have a way to ship automatic updates
> >   frequently enough to remove compromised CAs' certificates.
> >   => It is true we need a better automatic update story, especially
> >      for security patches, but that's not specific to CAs.
> >   => Removal mostly happens because of expiry or disuse, not for audit
> >      failure or compromise.  Although it does happen, removal for
> >      audit failure is rare, and removal for compromise is extremely
> >      rare.
> >   => Even before we implement automatic updates, under this proposal
> >      NetBSD security advisories can provide quick and easy steps for
> >      remediation to exclude individual CA certificates.

More details below.

>     Will the in-tree bundle be updated regularly?  I could probably live 
> with "Keep your NetBSD base system updated to keep your CA bundle 
> updated", but if I would rebuild my systems from the latest sources and 
> not get the latest bundle I'd probably find it to be a little annoying.

Yes, the idea is to keep it updated regularly.

The last upstream update was on 2023-07-19.  The last one before that
was 2022-11-29.  This is not high frequency, so it shouldn't be much
of a maintenance burden; we have other upstream software that updates
with higher frequency.  Here's the commit log:

https://hg.mozilla.org/projects/nss/log/tip/lib/ckfw/builtins/certdata.txt

The most recent security-relevant incident was on 2022-11-30 when
TrustCor flunked public scrutiny.  (But there was no evidence of
mis-issued certificates.)

>     Rhetorical Devil's advocate question:  What's the potential blast 
> radius for the worst case scenario where a CA's private key is 
> compromised before its certificate expires and a bunch of NetBSD users 
> don't update their bundle for two years?

This is no different from any other security issue on a machine on the
internet.

Once we have an automatic update system, upstream updates to
certdata.txt can be carried through it.

Until then, we can continue doing what we've been doing for security
issues: publish a security advisory.

The security advisory can include the following one-liner step for
remediation:

# certctl untrust /usr/share/mozilla/certs/server/Acme_Certs_and_Roadrunner_Traps.pem

Alternatively, you can keep doing what you were doing with (say)
mozilla-rootcerts or ca-certificates from pkgsrc, by overwriting
/etc/openssl/certs.conf as follows to ensure that, when you update
NetBSD, certctl(8) won't clobber the /etc/openssl/certs directory
populated by the package:

# cat <<EOF >/etc/openssl/certs.conf
netbsd-certctl 20230816
manual
EOF

Alternatively, you could use the certctl(8) utility together with the
static .pem files of mozilla-rootcerts or ca-certificates (updated
through pkgsrc or pkg_add or pkgin) by changing the search path in
/etc/openssl/certs.conf and rerunning `certctl rehash'.