On Fri, Mar 1, 2013 at 4:53 PM, Novosielski, Ryan <user-ae4522577e16@xymon.invalid>wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/01/2013 04:45 PM, Ralph Mitchell wrote:
On Fri, Mar 1, 2013 at 3:40 PM, <user-87556346d4af@xymon.invalid
<mailto:user-87556346d4af@xymon.invalid>> wrote:
[snip]
Perhaps user/pass authentication could be added, but "real"
security at the report-submission level would be SSL-handshaking at
the port with any local keys controlled by standard unix/host
access controls, (or HTTPS and xymonmsgcgi.msg and appropriate
user/pass auth info after the SSL tunnel is set up). The bits and
pieces are in trunk, but I'm not sure what their current working
state is...
I'm currently using xymoncgimsg.cgi to catch status messages sent
over HTTPS via curl. For what I'm doing, the client-side xymon
binary can be replaced by a script.
I'm not using client-side certificates, though that ought to be
fairly easy to add. The problem with any client-side
userid/password/certificate is that you have to have a plain text
password or key somewhere, so the whole security chain could
unravel if not done right.
Another piece of software I use, Bacula, can use SSL and does
validation against the CN field. I would think that would be a
reasonable solution. It also needs to pass a signature test. I would
think it would be pretty hard to fake a CN and then get it signed by
your in-house certificate authority, let alone VeriSign.
I'm working on setting up something similar to that - wifi network with
client certificates.
For the SSL handshake to work with certificates at both ends, they each
need to have a private key that matches their certificate. What I was
saying is that the client-side key has to be protected from any users on
the system. You can encrypt it, but then you'd need someone to type the
decrypting passphrase whenever the client starts up. Or you can put the
passphrase for the key in a file, but then it has to be clear text so you
might as well not bother. Or you can store the key in a hardware token or
smart card, which makes it extremely hard to copy.
And all of that's overkill for most of us - I'm just pointing out that it's
not just a certificate, there's a private key as well. Both need
protecting, because if I get your key, I *am* you...
Ralph Mitchell