On Fri, Mar 1, 2013 at 4:53 PM, Novosielski, Ryan <span dir="ltr"><<a href="mailto:novosirj@umdnj.edu" target="_blank">novosirj@umdnj.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div class="im"><br>
On 03/01/2013 04:45 PM, Ralph Mitchell wrote:<br>
> On Fri, Mar 1, 2013 at 3:40 PM, <<a href="mailto:cleaver@terabithia.org">cleaver@terabithia.org</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:cleaver@terabithia.org">cleaver@terabithia.org</a>>> wrote:<br>
><br>
> [snip]<br>
><br>
> Perhaps user/pass authentication could be added, but "real"<br>
> security at the report-submission level would be SSL-handshaking at<br>
> the port with any local keys controlled by standard unix/host<br>
> access controls, (or HTTPS and xymonmsgcgi.msg and appropriate<br>
> user/pass auth info after the SSL tunnel is set up). The bits and<br>
> pieces are in trunk, but I'm not sure what their current working<br>
> state is...<br>
><br>
><br>
> I'm currently using xymoncgimsg.cgi to catch status messages sent<br>
> over HTTPS via curl.  For what I'm doing, the client-side xymon<br>
> binary can be replaced by a script.<br>
><br>
> I'm not using client-side certificates, though that ought to be<br>
> fairly easy to add.  The problem with any client-side<br>
> userid/password/certificate is that  you have to have a plain text<br>
> password or key somewhere, so the whole security chain could<br>
> unravel if not done right.<br>
<br>
</div></div>Another piece of software I use, Bacula, can use SSL and does<br>
validation against the CN field. I would think that would be a<br>
reasonable solution. It also needs to pass a signature test. I would<br>
think it would be pretty hard to fake a CN and then get it signed by<br>
your in-house certificate authority, let alone VeriSign.<br></blockquote><div><br></div><div>I'm working on setting up something similar to that - wifi network with client certificates.</div><div><br></div><div>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.</div>
<div><br></div><div>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...</div>
<div><br></div><div>Ralph Mitchell</div></div>