[Xymon] XyMon client binaries default security is bad

Ralph Mitchell ralphmitchell at gmail.com
Sat Mar 2 06:44:25 CET 2013


On Fri, Mar 1, 2013 at 4:53 PM, Novosielski, Ryan <novosirj at umdnj.edu>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, <cleaver at terabithia.org
> > <mailto:cleaver at terabithia.org>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20130302/4fd3f0c7/attachment.html>


More information about the Xymon mailing list