[Nut-upsdev] Client certificates

[EmilienKia at Eaton.com]

> -----Message d'origine-----
> De : 
> nut-upsdev-bounces+emilienkia=eaton.com at lists.alioth.debian.or
> g 
> [mailto:nut-upsdev-bounces+emilienkia=eaton.com at lists.alioth.d
> ebian.org] De la part de Arjen de Korte
> Envoyé : mercredi 12 janvier 2011 09:59
> À : nut-upsdev at lists.alioth.debian.org
> Objet : Re: [Nut-upsdev] Client certificates
> 
> Citeren EmilienKia at 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).
> 

If you think that login/password is enought to authenticate clients, I can remove SSL client authentication parts. It is not a problem.

> > 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.


I have implemented SSL/NSS in the upscli part, not directly in upsmon.
Actually, just upsmon uses it but, ideally, all clients should use SSL to dialog with upsd.

BR
Emilien

--------------------------------------------------------------------------