[Nut-upsdev] TLS support in NUT

[Jim Klimov]

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>