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