[Nut-upsdev] TLS support in NUT

[Roger Price]

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