Nut upsdev - Jun 2021 - TLS support in NUT

On a related note, we have got a pull request
https://github.com/networkupstools/nut/pull/1043 submitted today, to add a
way of limiting the use of obsoleted ciphers in a NUT deployment. Reviews
and comments in the PR are welcome :)

Jim

On Fri, May 28, 2021 at 11:13 AM Roger Price <roger at rogerprice.org>
wrote:
> On Tue, 25 May 2021, Jim Klimov wrote:
>
> > Just dropping a couple of comments/questions here:
> >
> > 1) Does IETF also require use of TLS for communications inside one
host
> (over
> > localhost)?
>
> You have put your finger on a basic NUT exposure!
>
> First of all: The IETF's view of security is in RFC 3552
> https://datatracker.ietf.org/doc/html/rfc3552 in which clause 5 covers
> "Writing
> Security Considerations Sections". In a Standards Track RFC authors
MUST
> describe
>
>        1.   which attacks are out of scope (and why!)
>        2.   which attacks are in-scope
>        2.1  and the protocol is susceptible to
>        2.2  and the protocol protects against
>
>     At least the following forms of attack MUST be considered:
> eavesdropping,
>     replay, message insertion, deletion, modification, and
> man-in-the-middle.
>     Potential denial of service attacks MUST be identified as well.
>
> In our case, an attack on the lo interface is in-scope, and an attacker
> could
> eavesdrop the plain-text password.  If this threat is deemed real in a
> given
> installation then we should say in the NUT documentation that the box
> running
> upsd should be single-user accessible by the sysadmin only.
>
> Our future RFC is not Standards Track and we are not held to the highest
> standard.  But we should say something.  Quoting RFC 3552 clause 5: ?While
> it is
> not a requirement that any given protocol or system be immune to all forms
> of
> attack, it is still necessary for authors to consider as many forms as
> possible.?
>
> I took the point of view that sniffing localhost traffic was unlikely
> since NUT
> server and client are not generally accessible. One would not use a
> machine
> serving employees/students for UPS management.
>
> > 2) Would a solution for two separate hosts be acceptable, where two
> TLS-Shims
> > are started:
> > * one listens on the NUT server's network interface(s) and passes
> unencrypted
> > packets to upsd on localhost (or via pipe) and replies back to the
net,
> > * another runs on client connecting to the NUT server, and the
> unmodified NUT
> > clients connect to it on localhost (or via pipe) with the plaintext
NUT
> > protocol?
>
> This is exactly the configuration I designed the shims for, and which I
> have
> tested.  I did not consider pipe interfaces to upsd and client since that
> required modification of NUT code.
>
> The IETF consider two separate hosts across the Internet to be the base
> case.
> Quoting again from RFC 3552:
>
>     The threat environment addressed by the Security Considerations
>     section MUST at a minimum include deployment across the global
>     Internet across multiple administrative boundaries without assuming
>     that firewalls are in place, even if only to provide justification
>     for why such consideration is out of scope for the protocol.  It is
>     not acceptable to only discuss threats applicable to LANs...
>
> > This would be similar to use of stunnel (or maybe would just use
stunnel
> if
> > tested and deemed acceptable) to connect plaintext sides of the dialog
> using a
> > secure channel.
> >
> > 3) In any case, having some solution for certificates is good,
although
> people
> > bothering about that (and a need to update the trust as these expire)
> might
> > opt for a private CA and would trust its longer-lived cert instead
>
> The proposed script generates certificates with unlimited validity ?Dec 31
> 23:59:59 9999 GMT? as defined by RFC 5280 para 4.1.2.5.
>
> Roger_______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20210612/7f515d1b/attachment.htm>

On Sat, 12 Jun 2021, Jim Klimov wrote:
> On a related note, we have got a pull request 
> https://github.com/networkupstools/nut/pull/1043 submitted today, to add a
way
> of limiting the use of obsoleted ciphers in a NUT deployment. Reviews and 
> comments in the PR are welcome :)
I would like to comment more generally on TLS support in NUT.  The pull request 
is part of a project move to continue supporting up to date encryption of 
communications, but it also raises more general questions:

1) The NUT project supports two TLS implementations: OpenSSL and NSS.  The 
administrative setups in upsd.conf and upsmon.conf for the two differ.  In both 
cases it is accepted that the NUT system administrator will be using commercial 
certificates, with all the administrative complexity that commercial 
certificates imply.  Should this be the case?

2) For the experimental TLS shims upsdTLS.py and upsmonTLS.py, and for the 
experimental client UPSmon.py, I took the position that the NUT project should 
help the system administrator as much as possible in the certificate management.
The required certificates are provided by script mkNUTcert.py which produces a 
pair of self-signed certificates specifically for use by NUT.  These provide 
better security, and are simpler to manage: the script knows where the files go.
There is no hashing, no CSR or other complexity.  It seems to me that the NUT 
project could usefully move to "self-signed certificates preferred".

3) Does the NUT project need two implementations of TLS?

4) I hope that in the long term, if the proposed RFC is accepted, port nut/3493 
will remain "TLS on request using command STARTTLS", but port ups/401
will be
"TLS required".

5) Is it possible to configure upsd.conf as follows:

  LISTEN <interface> 3493
  LISTEN <interface> 401

and listen on two ports?  I havn't tried it.

Roger