tech-crypto archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[PATCH] HTTPS/TLS CA certificates in base



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



Home | Main Index | Thread Index | Old Index