> -----Message d'origine----- > De : > [email protected] > g > [mailto:[email protected] > ebian.org] De la part de Arjen de Korte > Envoyé : mercredi 12 janvier 2011 09:59 > À : [email protected] > Objet : Re: [Nut-upsdev] Client certificates > > Citeren [email protected]: > > > 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 -------------------------------------------------------------------------- _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
