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

[Thor Lancelot Simon <tls%panix.com@localhost>]

I would like to be sure we will avoid any use of public CA's certificates
to establish trust for upgrades of NetBSD itself, or of packages.  Otherwise,
we will find ourselves in a situation where we can never recover if a CA
goes rogue.

Thor

On Sat, Aug 19, 2023 at 04:51:29PM +0000, Taylor R Campbell wrote:
> 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.)



-- 
  Thor Lancelot Simon	                                     tls%panix.com@localhost

  "The inconsistency is startling, though admittedly, if consistency is to
   be abandoned or transcended, there is no problem."	      - Noam Chomsky