Submiting patch for nrpe

[Stephen Strudwick]

> What you don't want to do is encrypt your datastream, and then send it through
> a TLS connection.  You're just wasting cycles in that case.  TLS solves a lot
> of security problems that most people don't think about; that's why it's a
> complex protocol.  :)

I dont see cpu cycles really being a problem, certainly not server
side, possibly it could add up a bit client side where nagios is
installed. But its just a handshake and exchange of 1k packets every 5
mins per server.

I wouldnt have thought it was wasted cpu cycles either, you would be
adding an extra layer of security, but more importantly providing some
kind of authentication lacking atm because of no certificates.

Anyway, im no expert on SSL/TLS, but im trying when I have spare moments
to read as much as possible, if im wrong, try to point me in the right
direction as to why.

> I would _love_ it if nrpe and nsca used TLS and provided support for
> certificate checking; it would simplify managing clusters of machines by quite
> a bit, as I would have one less auth mechanism to worry about.

For me the problem atm is the lack of certificates. I would have preferred
this approach, but I dont know enough about SSL/TLS and I didnt have the
time to learn/experiment and implement.

I went with blowfish because I knew I could get something
secure, reliable and already fully tested working in a few days.

-
Stephen Strudwick
Advanced Development Engineer
Development Group, Product Development
PIPEX Communications
http://www.pipexcommunications.net/

Mobile: 07906 191256
Direct: 020 8957 1217

On Wed, 21 Jan 2004, Mark Ferlatte wrote:

> Ethan Galstad said on Tue, Jan 20, 2004 at 11:45:26PM -0600:
> > Hi Stephen -
> >
> > The patch applied cleanly, but I might hold off on comitting it to
> > CVS.  The reason for this is I think the encryption should probably
> > be used on top of SSL, rather than instead of it.  I think one of the
> > big reasons for using SSL/TLS connections is the fact that its harder
> > to do "replay" attacks and fake check results.  If we go with crypto
> > on top of the TLS connection, I would probably look at brining back
> > optional support for the mcrypt() library, which handles a number of
> > crypto algorithms (including Blowfish).  Anyone have comments on this
> > approach?  I'm not an SSL/TLS/crypto expert by any means, so I might
> > be totally off-base. :-)
>
> Sorry, I haven't been tracking nrpe/nsca development recently, but:
>
> If you have SSL/TLS, you should use that for encryption also; it's part of the
> protocol.
>
> What you don't want to do is encrypt your datastream, and then send it through
> a TLS connection.  You're just wasting cycles in that case.  TLS solves a lot
> of security problems that most people don't think about; that's why it's a
> complex protocol.  :)
>
> I would _love_ it if nrpe and nsca used TLS and provided support for
> certificate checking; it would simplify managing clusters of machines by quite
> a bit, as I would have one less auth mechanism to worry about.
>
> M
>



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn