[Nut-upsdev] TLS, was [IANA #1182277] AutoReply: Port Number (3493) Modification

[Roger Price]

On Wed, 11 Nov 2020, Jim Klimov wrote:

> I agree with you. Probably similar could be done with stunnel, to avoid 
> maintaining in NUT a fast moving target of modern cryptography. And indeed it 
> may be better in terms of switching real deployments to new protocols if old 
> ones are deemed insecure, with implementations made by people hopefully better 
> knowledgeable about the nuances involved, and/or just more exposed to discover 
> and fix security bugs faster.

Python3 provides a very thin wrapper around openSSL's TLS.  This exposes the 
default openSSL options which automatically call for the most recent version of 
TLS and reject the old deprecated SSL versions.  This simplifies maintenance. 
The certificates which are also created using a thin Python3 wrapper around 
openSSL also benefit from the default "most secure" options.  However it is 
essential to read RFC 5280 (Internet X.509 Public Key Infrastructure 
Certificate), and presumably whatever will replace it in a couple of years.

> One of my later points was that a dedicated solution (here SSL wrapper) on a 
> dedicated port may be also a limiting factor. If a dialog is expected to start 
> in a specific crypto protocol mode, 

The openSSL dialog starts using the default "most secure" options, but without 
specifying them.  Working out the details is for openSSL.

> it may be problematic to talk a completely different protocol on the same port 
> in the future. STARTTLS or similar approaches elude that, by talking initially 
> in a future-proof (e.g. plaintext) protocol and there agreeing on capabilities 
> and desires of the sides. 

> That said, a crypto protocol designed to be extensible might avoid that too. 
> Given how the web or SMTPS iterated through generations of SSL and TLS, it may 
> be not a bottleneck either.
> 
> Jim

> 
> On Wed, Nov 11, 2020, 17:28 Roger Price <roger at rogerprice.org> wrote:
>       On Wed, 11 Nov 2020, Jim Klimov wrote:
>
>       > Interesting, thanks. 
>       > But given the limited amount of port numbers, in IANA's shoes I'd suggest to consider enabling STARTTLS (like in SMTP) so switching into
>       security mode
>       > could be negotiated in a single-port dialog. Especially as NUT protocol is text-based similarly.
>       >
>       > Back in my ISP providering days, we had similar paperwork to prove to self and others why we need the limited resource of more IPv4 address
>       ranges.
>       >
>       > I suppose for STARTTLS we could inspire from sendmail or other such daemons.
>       >
>       > Would that make sense to you? It is likely more complex than hardcoding the default port for SSL wrapping, if we are easily given one. But
>       still it may be
>       > more simple to manage (think firewall rules) too... And potentially more extensible to dynamically switch into more future protocol
>       versions.
>
>       NUT is a mature project which will continue to advance at a "mature" speed.
>       However TLS moves quickly and in little time previous versions are deprecated
>       and refused.  I wrote a thin daemon to sit next to upsd which receives TLS
>       encoded traffic on port 401 at the latest security level, and relays it to upsd
>       on port 3493.  It currently runs on Debian and openSUSE, and seems to me to be a
>       way in which NUT could meet all network security obligations, without upsetting
>       the regular development cycle.  For such an approach, two ports are essential.
>
>       Roger