TL;DR -- I propose to:
- Ship Mozilla's root CA certificates in base.
- Have ftp(1) and pkg_add(1) use them for TLS validation by default.
- Provide ways for you to persistently:
. exclude individual CA certificates,
. add to or change the root CA set altogether, or
. let something else like a pkgsrc package manage /etc/openssl/certs,
so that upgrading NetBSD won't override your TLS trust root
decisions.
Objections?
BACKGROUND
It has long been an embarrassment that a base install of NetBSD can't
do TLS validation in programs such as ftp(1) and pkg_add(1).
Some objections in the past included:
- TNF shouldn't be telling people which CAs to believe about anything
other than TNF business.
=> This proposal makes it easy for users to persistently configure
their own systems to use different root TLS CAs, without losing
that configuration on upgrades. It only improves the
out-of-the-box experience.
- 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.
- We can't do this until we have a way to ship automatic updates to
frequently enough to add new CAs' certificates.
=> It is true we need a better automatic update story but that's not
specific to CAs.
=> New CAs are infrequently added, only a few times a year, and
everyone expects they will take some time to be deployed before
they can be reliably used by most users, along the time scales of
NetBSD releases. There have been a total of 120 individual
updates in the past decade -- an average of one per month, but
many of them have been in batches of separate hg commits on a
single day at a time.
=> If you need newer root CA certificates on a shorter time scale
than a NetBSD release cycle, you can add more -- from pkgsrc,
from privately installed sets in /usr/local, or wherever. These
can replace or add to the Mozilla root CAs in base.
- We already have a perfectly good authenticated path to install
certificates if you want.
=> Technically true. TNF ssh host keys are preinstalled in
/etc/ssh/ssh_known_hosts, and you can check pkgsrc out of CVS via
anoncvs authenticated this way, and then build your own
mozilla-rootcerts or ca-certificates package, provided you have
comp.tgz installed so pkgsrc works.
=> While technically true, this is an abysmal user experience for
what is today a basic requirement of any real participation on
the internet. Instead, most users are probably simply unaware
that the web's primary defence against tampering is just quietly
missing in NetBSD.
- We shouldn't trust Mozilla's decisions.
=> Mozilla is part of the CA/Browser forum, which these days is a
reasonable system of governance with serious audit requirements
that CAs sometimes actually fail with the consequence of removal.
=> Of the members in the forum, Mozilla is another 501(c)(3)
not-for-profit and is most aligned with TNF's goals, and makes
certdata.txt available under a free software licence.
=> I expect most users (who are aware of the omission in base)
already do trust Mozilla's decisions by installing the
mozilla-rootcerts or ca-certificates packages.
=> Users who want to make different decisions will have an easy way
to persistently do so.
- The CA business is a protection racket.
=> This ceased to be so with Let's Encrypt, many years ago by now.
BIKESHEDDY DETAILS
- Mozilla root CA certificates from nss certdata.txt get installed in
/usr/share/certs/mozilla/all, with symlinks into it at
/usr/share/certs/mozilla/server for all of those trusted by Mozilla
for server authentication (i.e., TLS, including HTTPS).
Certificates marked DISTRUST_AFTER any date are excluded; there's no
standard mechanism to pass this information through to OpenSSL as
far as I know.
(As a potential convenience, the email and code-signing ones are
also symlinked at /usr/share/certs/mozilla/email and
/usr/share/certs/mozilla/code, but nothing uses those directories at
the moment. Certainly /usr/share/certs/mozilla/code is _not_ used
for code-signing any kind of NetBSD updates.)
- OpenSSL-based applications use the directory /etc/openssl/certs or
the file /etc/openssl/certs/ca-certificates.crt to find TLS CA
certificates, as they do already -- no change to the
application-visible interface.
- New command certctl(8) manages /etc/openssl/certs and
/etc/openssl/certs/ca-certificates.crt as a cache of hashed
symlinks.
. Simple configuration file /etc/openssl/certs.conf specifies search
path (default: /usr/share/certs/mozilla/server), or `manual' to
prevent certctl(8) from touching /etc/openssl/certs at all so you
can manage it another way (e.g., security/mozilla-rootcerts or
security/ca-certificates in pkgsrc).
. `certctl untrust /path/to/foo.pem' excludes that certificate from
/etc/openssl/certs, by symlinking it in /etc/openssl/untrusted.
. If /etc/openssl/certs is damaged or lost, `certctl rehash'
rebuilds it from the configuration file and the list of
exclusions.
The command-line syntax is mostly compatible with FreeBSD's
certctl(8), but FreeBSD's certctl(8) treats /etc/ssl/certs and
/etc/ssl/untrusted as _both_ configuration _and_ a cache, whereas
this proposal treats /etc/openssl/certs strictly as a cache for the
configuration in /etc/openssl/certs.conf and /etc/openssl/untrusted.
I believe this proposal is more useful than the FreeBSD semantics:
it means, e.g., you can run `certctl rehash' (e.g., automatically
via postinstall(8)) after an upgrade and it won't forget your
`certctl untrust' decisions.
- When run in DESTDIR=/, postinstall(8) runs `certctl rehash' to make
sure /etc/openssl/certs is populated.
Note: This is limited to DESTDIR=/, and will not happen in
cross-built destdirs, because it requires running openssl(1), and we
don't have openssl(1) hooked up to the tools build, nor do we
currently require the build environment to support it.
If we changed either of those we could lift the restriction of
DESTDIR=/ for postinstall(8) to run `certctl rehash'. (An
alternative would be to test whether `type openssl' succeeds, but
that strikes me as a little sketchier.)
Attachment:
nbcerts.patch.gz
Description: application/gzip