[Nut-upsdev] Client certificates

[Arjen de Korte]

Citeren EmilienKia op Eaton.com:

> I have added client certificate checking mainly to avoid  
> man-in-the-middle attacks or identity usurpation.

A man-in-the-middle attack is impossible if you verify the server  
certificate (CERTVERIFY 1). If someone manages to stage a  
man-in-the-middle attack by providing a certificate that is trusted by  
your clients CA store, you have bigger worries than this.

> Indeed If you just have server authentication (like 99% the web  
> where just the sertver auth is required), you are just sure of the  
> server's identity, but not the client's one.

That's why we have users defined in 'upsd.users'. Generally speaking,  
we want to grant/limit access to a role/person (user/password) rather  
than a machine (client).

> If you do not want that a vilain execute vicious commands (if it has  
> the login/password), the server must be sure of the client's identity.

I see no difference here. You're using the same file (upsmon.conf) to  
store the existing user/password mechanism and the information to use  
a client certificate. If someone unauthorized is able to read this  
file, you're toast either way, so the client certificate is not adding  
to the security here.

In general, you should have at least three different users defined in  
upsd.users:

     upsslave - only able to read status information from the server
     upsmaster - same as the above, but can also initiate a FSD
     admin - can issue instant commands and change settings

The admin account should *never* be used in 'upsmon.conf' and only be  
used by operators for changing settings or initiating instant  
commands. Practically they should use a secure shell to connect to the  
upsd server and issue the commands there. So most of the time, you'll  
want to limit access to this account to the localhost interface only  
(maybe additionally the webserver too, if you use that for remote  
administration).

> Moreover, note that the password is exchenaged uncrypted or unhashed  
> (do not take in account the SSL tunnel) so nothing can prevent a  
> manè-in-the-middle attack because the server can not detect it  
> speaks to a vilain (or a client via a vilain) and not directly to  
> the real client.

If you can't trust your network (which in the vast majority of the  
cases is not the case, because it will be internal), use SSL  
encryption. It is then the responsibility of the client to not sent  
username/password if it can't verify the server certificate (which is  
the case in upsmon already).

Generally speaking a client will be aware that it is talking to the  
server over an untrusted network (for instance, an operator monitoring  
a UPS in a remote location). In that case, 'CERTVERIFY 1' will make  
sure the user/password information remains secure.

Also note that the amount of mischief a upsmon client can do, is  
limited to initiating a FSD if it is in master mode only. Changing  
settings and initiating instant commands is limited to the upsrw and  
upscmd tools respectively, which don't use encryption at all. This  
means that these can only be run securely on the remote system itself  
(for instance in a ssh).

I'm still not convinced that client certificates are needed/useful for upsmon.

Best regards, Arjen
-- 
Please keep list traffic on the list (off-list replies will be rejected)