> be used on top of SSL, rather than instead of it.
I never thought of adding it this way, It should be easy to change
however, the code should work on top of SSL with no problems.
I might do this and submit another patch.
> 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).
I understand why you would want to do this, the only problem is I dont
think theres a port of mcrypt() for windows NT ?
I know the nrpe_nt is really a seperate branch to the nagios code, but I
really like the fact that nrpe_nt has the same code and functionality as
nrpe (unix). It might be a bit more difficult to keep this using mcrypt.
I might be wrong tho.
The reason I used this encryption code instead of mcrypt is that we
developed it in house about 4 years ago originaly to sync UNIX/NT
databases encrypted and then later much for the same reson mcrypt
was written (the code I added to nrpe is ripped out from a larger
set of perl/c modules and NT DLL's).
This meant it was easier to maintain compatibility with the NT code.
I ported the blowfish changes to nrpe_nt last week and its pretty much
line for line the same as the unix version, I will release a patch for
this asap.
Anyway, at the end of the day I need the encrypted authentication blowfish
provides. In the short term I will use these patches, if something similar
is released by nagios that does the same job I will use that instead.
In the mean time, any changes I make I will also make available, simply
because its a bonus for our operations department to be able to use an
offical release than a in house patched release.
-
Stephen Strudwick
Advanced Development Engineer
Development Group, Product Development
PIPEX Communications
http://www.pipexcommunications.net/
Mobile: 07906 191256
Direct: 020 8957 1217
On Tue, 20 Jan 2004, Ethan Galstad wrote:
> 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.
>
>
> On 14 Jan 2004 at 15:33, Stephen Strudwick wrote:
>
> > Hi all,
> >
> > attached is a patch for nrpe that enables blowfish encryption as a
> > compile time option.
> >
> > This is a large patch, so I also have an html document attached
> > describing the patch and how to apply/use it.
> >
> > The patch should be applied to the latest CVS tree for nrpe, not the
> > released tar.gz.
> >
> > I would really appreciate it if it could be considered for addition to
> > the cvs tree, and any criticisms etc welcome.
> >
> > On a related note, I am also preparing a similar patch for nrpe_nt,
> > and I also have a load of C plugins almost ready for release for
> > nrpe_nt, hopefully they will be ready by the end of the week.
> >
> > -
> > Stephen Strudwick
> > Advanced Development Engineer
> > Development Group, Product Development
> > PIPEX Communications
> > http://www.pipexcommunications.net/
> >
>
>
>
> Ethan Galstad,
> Nagios Developer
> ---
> Email: [email protected]
> Website: http://www.nagios.org
>
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Nagios-devel mailing list
> N
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]