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).
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)
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
