During work on #3228/#1711 I found that only upsmon currently has code and configuration options to set up SSL connections. Other clients just "try ssl" in their upscli_init() or similar calls, and happily go on in plaintext (to check: maybe they do STARTTLS trusting any server with NUT protocol support, which is marginally better than plaintext?). This may be behind the infamous "Init SSL without certificate database" messages from upsc - the value is never known by client nor passed to the library, and could be especially unfortunate IF it never does SSL in the first place (to check, as noted).
This relaxedly unsafe may be okay-ish for read-only anonymous streams (upsc, upslog, upsstats.cgi, upsimage.cgi, nut-scanner, possibly dummy-ups as a read-only relay -- though even there MITM attacks may be a concern for monitoring systems that base decisions on what they get from a NUT data server), but is nowadays frowned upon for authenticated sessions and so logins/passwords, variable setting and instant command sending (upsrw, upscmd, upsset.cgi at least; perhaps NUT-Monitor UI also, although that is rather a matter to solve with issue #1600; dummy-ups if it ever becomes a writing relay for INSTCMD/SETVAR) even in a local network.
This issue tracks that we have this problem, and should devise some common set of CLI arguments (especially for clients currently without config files).
Probably a more flexible and future-proof idea (especially given the difference of OpenSSL vs NSS functionality at the moment) is to define a config file for such auth details (excerpt from upsmon.conf?) that could be used if present, and add one option to the clients to let them select an alternative file (e.g. to use a different client cert per client program, for cases such as one NUT installation monitoring multiple "unrelated" servers).
See also:
Might be related:
CC @clepple @aquette
UPDATE: In the test suite now updated to try SSL, at least upsc does report e.g.
Connected to NUT server localhost in SSL
Certificate verification is disabled
...so at least the basic crypto setup (when the server is willing) does work. Still, the client currently can't/doesn't care about server identity. Exporting SSL_CERT_DIR (for OpenSSL-capable builds) does not change this.
Non-SSL tests (C++, Python) also pass, at least for OpenSSL builds (without client identity being in question). And for NSS, when built/configured without client validation (again, upsc does not configure the server cert ID):
Connecting in SSL to 'localhost' (no certificate name specified)
Do not intend to authenticate server localhost
SSL handshake done successfully with server localhost
Connected to NUT server localhost in SSL
Certificate verification is disabled
During work on #3228/#1711 I found that only
upsmoncurrently has code and configuration options to set up SSL connections. Other clients just "try ssl" in theirupscli_init()or similar calls, and happily go on in plaintext (to check: maybe they do STARTTLS trusting any server with NUT protocol support, which is marginally better than plaintext?). This may be behind the infamous "Init SSL without certificate database" messages fromupsc- the value is never known by client nor passed to the library, and could be especially unfortunate IF it never does SSL in the first place (to check, as noted).This relaxedly unsafe may be okay-ish for read-only anonymous streams (
upsc,upslog,upsstats.cgi,upsimage.cgi,nut-scanner, possiblydummy-upsas a read-only relay -- though even there MITM attacks may be a concern for monitoring systems that base decisions on what they get from a NUT data server), but is nowadays frowned upon for authenticated sessions and so logins/passwords, variable setting and instant command sending (upsrw,upscmd,upsset.cgiat least; perhaps NUT-Monitor UI also, although that is rather a matter to solve with issue #1600;dummy-upsif it ever becomes a writing relay for INSTCMD/SETVAR) even in a local network.This issue tracks that we have this problem, and should devise some common set of CLI arguments (especially for clients currently without config files).
Probably a more flexible and future-proof idea (especially given the difference of OpenSSL vs NSS functionality at the moment) is to define a config file for such auth details (excerpt from
upsmon.conf?) that could be used if present, and add one option to the clients to let them select an alternative file (e.g. to use a different client cert per client program, for cases such as one NUT installation monitoring multiple "unrelated" servers).See also:
libupsclientactually used by the clients, add SSL tests with NIT where possible #3328Might be related:
CC @clepple @aquette
UPDATE: In the test suite now updated to try SSL, at least
upscdoes report e.g....so at least the basic crypto setup (when the server is willing) does work. Still, the client currently can't/doesn't care about server identity. Exporting
SSL_CERT_DIR(for OpenSSL-capable builds) does not change this.Non-SSL tests (C++, Python) also pass, at least for OpenSSL builds (without client identity being in question). And for NSS, when built/configured without client validation (again,
upscdoes not configure the server cert ID):