[Nut-upsdev] Common NUT client auth setup

[Greg Troxel]

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:

>   While finalizing the NUT v2.8.5 release, I've stumbled on some issues and
> delayed them for the next release cycle(s). One of these is the realization
> that very few NUT clients are fully SSL capable (as in saying who they are
> and what servers they trust). Due to this most users probably can not
> enable CERTVERIFY on servers, as only upsmon of all stock NUT clients would
> be able to talk to them.

This is not really about nut.  Having client certificates and using them
for authentication is very unusual.  Existing practice is almost
entirely to have a server have a certificate, and to have that
verifiable via pkix norms, either because it's part of the normal public
PKI (mozilla rootcerts, ish) or because a private CA has been
configured.

The normal path is to use username/password, openidconnect, or some
other auth scheme within the TLS session after the client is sure they
are talking to the real server.  Or maybe even Kerberos.

Extending this to certificates for client use crosses into rare
practice.  LE in particular is no longer issuing certs usable for this,
as I understand it, so you're likely in private PKI territory.

I would say the first question is who actually trying to use client
certs, and does this make any sense to put time into.  My reaction is
that it's work and complexity for no practical usage.

>   Similarly, further ideas include somehow equalizing the abilities of
> OpenSSL and Mozilla NSS backends, so the choice is more of licensing
> philosophy than technical constraints:
> https://github.com/networkupstools/nut/issues/3331

Do you really believe that there are actual nut users that are wanting
to restrict pkix validation to only certain CAs, or engage in pinning
for nut, while not wanting to have the same kind of restricted CA set
system-wide?  I find that surprising.

But, adding ability to configure that as a client does not seem harmful,
other than the general costs of more lines of code for zero users.  Is
there existing practice for other programs that connect via TLS, in
terms of common interfaces and config options?  It would be good to do
it the conventional way.

>   And taking it a bit further (licensing preferences permitting), why not
> build-in both backend supports and let the run-time choose which to use (at
> least useful while features differ)?
> https://github.com/networkupstools/nut/issues/3332

I hold that

  - almost all uses [of any widely-used program] will be via a packaging
    system

  - when packaging

    + one wants to include dependencies that result in the program
      working better or doing more things.

    + one wishes to avoid dependencies that take up space, require more
      building, or cause cognitive load from their presence, when they
      do not materially improve how the program works for the user

  - I have no memory of encountering a program that links with more than
    one of openssl, nss, gnutls, etc.  Yes, there are programs that can
    choose at build time, and sometimes pkgsrc has a build option to
    choose, for people that care, but the default is usually openssl.  I
    have never found a package that links with both.


I don't think this makes sense.  It's a lot of complexity, and packaging
systems aren't going to build with multiple ssl libs at the same time.
People that want to choose something else can build -- it's not that
hard, and if it is, fixing that is more important -- either by hand or
via a packaging option.

Before proceeding, I think we should be hearing from other packagers,
and specifically whether, if nut could be built with both openssl and
nss, they would configure their package to *by default so it is the
standard distributed binary* to depend on both.

My prediction is that nobody will say that, but I hope there is a
packager on this list Debian, FC, suse, arch?, gentoo, FreeBSD, OpenBSD,
homebrew, macports, and probably something else.  (I'm unclear on
packaging for a large number of GNU/Linux systems that don't derive from
Debian, Fedora, or suse).