Debian Bug report logs - #547092
nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian systems

[Message part 1 (text/plain, inline)]
Package: nagios-nrpe-server
Version: <= 2.12
Severity: important
Tags: patch

The SSL option of the NRPE plugin and server does not perform any kind of authentication. It has no certificates, only a DH key, which is generated at compile time.

This means that the nrpe key is identical to all debian systems, but subject to change every time the package maintainer uses the  ./configure script.

My patch adds full SSL certificate verification to nrpe. Note that this breaks backwards commandline compatibility, because the previous mode was insecure. This means that the check_nrpe rules must be edited in the nagios configuration as well.

-- System Information:
Debian Release: 5.0.3
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

[fullssl.patch (text/x-diff, attachment)]
tag 547092 upstream
thanks

Hi, 

I saw that I should maybe at some information to the bug. We discussed the
problem a few time on the mailinglist and the think that debian is the wrong
place for the patch. Such a patch belongs upstream as the problem is in no
way debian specific but binary distribution specific a clear design flaw. 

There is also an issue in the upstream bugtracker:
http://tracker.nagios.org/view.php?id=125 to follow the problem. 

I hope that make things clearer. 

Alex

tag 547092 + security
stop

Hey.

The upstream bug is now more than 2 years old... and upstream is well 
known for doing nothing (which is the reason for icinga/shinken)...

Can't we just integrate this in Debian's nrpe?

Cheers,
Chris.

Hi.

I've just seen that this is already solved in Icinga's version of NRPE:
https://dev.icinga.org/issues/291

Cheers,
Chris.

Christoph Anton Mitterer schrieb am Monday, den 20. February 2012:

> tag 547092 + security
> stop
> 
> Hey.
> 
> The upstream bug is now more than 2 years old... and upstream is
> well known for doing nothing (which is the reason for
> icinga/shinken)...
> 
> Can't we just integrate this in Debian's nrpe?
this breaks all existing nrpes and icinga nrpe is not in a releasable state.

Alex

-------- Original Message  --------
Subject: [Pkg-nagios-devel] Bug#547092: solved in icinga
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 547092@bugs.debian.org
Date: 2012-02-20 01:51
> Hi.
>
> I've just seen that this is already solved in Icinga's version of NRPE:
> https://dev.icinga.org/issues/291

although i appreciate the mention, this remains "in development" and 
unless there aren't proper tests as well as other patches resolved, this 
won't be released soon.

so "solved" isn't the correct description. it's "feedback" time.

https://dev.icinga.org/projects/core-nrpe/roadmap
>
> Cheers,
> Chris.
>
>
>
> _______________________________________________
> Pkg-nagios-devel mailing list
> Pkg-nagios-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nagios-devel

-- 
DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email:  michael.friedrich@univie.ac.at
phone:  +43 1 4277 14359
mobile: +43 664 60277 14359
fax:    +43 1 4277 14338
web:    http://www.univie.ac.at/zid
        http://www.aco.net

Lead Icinga Core Developer
http://www.icinga.org

Hello all,

On Mon, Feb 20, 2012 at 06:29:54AM +0100, Alexander Wirt wrote:
> Christoph Anton Mitterer schrieb am Monday, den 20. February 2012:
> > The upstream bug is now more than 2 years old... and upstream is
> > well known for doing nothing (which is the reason for
> > icinga/shinken)...
> > 
> > Can't we just integrate this in Debian's nrpe?
> this breaks all existing nrpes (...)

JFTR, Russell Coker worked around this breakage as detailed in
http://etbe.coker.com.au/2009/12/14/nagios-and-ssl-in-debian/

This might not be suitable for a distribution like Debian, but
individual admins might want to follow suit. Or migrate to NRPE-less
setups with checks conducted via SSH with pubkeys and possibly using
check_multi and/or check_mk ...

Cheers,
Flo

[Message part 1 (text/plain, inline)]
Hi Alexander.

On Mon, 2012-02-20 at 06:29 +0100, Alexander Wirt wrote:
> this breaks all existing nrpes
What do you mean by breaking NRPEs? 
The other Nagios NRPEs (that could be used on remote host sides) which
still use the fake SSL?

But even if it does... wouldn't that be better? That SSL is just
useless, so admins are better off with disabling it altogether.

> and icinga nrpe is not in a releasable state.
Just for my personal education :) ... what's the issue about it?

I mean the current situation is IMHO a bit concerning.
- Nagios upstream seems to have abandoned this issue.

- SSL is activated per default in Debian, which is useless anyway and in
the worst case gives a wrong feeling of security.

- Severity of this issue is "just" important, IMHO it should be grave
(http://www.debian.org/Bugs/Developer#severities), which would also
notify at least those using apt-listbugs.

- Of course one can argue that you cannot do much of an attack with
NRPE, but people may rely on SSL and think it safe because of it to
enable argument processing in NRPE

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]
-------- Original Message  --------
Subject: [Pkg-nagios-devel] Bug#547092: Bug#547092: nagios-nrpe-server: 
Insecure 'SSL' option, key identical for all debian systems
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 547092@bugs.debian.org
Date: 2012-02-20 13:14
> Hi Alexander.
>
> On Mon, 2012-02-20 at 06:29 +0100, Alexander Wirt wrote:
>> this breaks all existing nrpes
> What do you mean by breaking NRPEs?

https://git.icinga.org/?p=icinga-nrpe.git;a=commit;h=025334c19f252f43c4ae8209ff1eec889908478b

especially, 
https://git.icinga.org/?p=icinga-nrpe.git;a=blobdiff;f=src/nrpe.c;h=1618be253465e3201ca0c988e176727f77abf8fa;hp=f5859b7a0c4c0aea7246a75fdf0d4c712106c68a;hb=025334c19f252f43c4ae8209ff1eec889908478b;hpb=b3eacf64ff33198c300f8ae72c77eedc91095093

> The other Nagios NRPEs (that could be used on remote host sides) which
> still use the fake SSL?

that code is not (yet) compatible. feel free to provide upstream patches 
which solve that compatibility breakage problem.

>
> But even if it does... wouldn't that be better? That SSL is just
> useless, so admins are better off with disabling it altogether.

the packaged version remains "rather useless" as the generated dh key 
happens on configure. so installing the built binary package isn't that 
security aware, though the source install does generate a new dh key 
everytime you call configure. by that means, upstream probably does not 
see the opportunity to include such patches/changes with high priority.

and with upstream, i do mean the official nagios nrpe project. the 
icinga one is just an unofficial fork, trying to collect various 
community patches, and if worth the squeeze, release as seperate 
version. but this is not yet decided when and where, because there isn't 
any official maintainer (within the icinga project).

>
>> and icinga nrpe is not in a releasable state.
> Just for my personal education :) ... what's the issue about it?

as pointed out previously, read the development tracker, especially the 
issues and the roadmap. there's a reason i'm posting those urls.

>
>
> I mean the current situation is IMHO a bit concerning.
> - Nagios upstream seems to have abandoned this issue.

this isn't news for anyone in the nagios space. can you do better than 
just telling us?

>
> - SSL is activated per default in Debian, which is useless anyway and in
> the worst case gives a wrong feeling of security.

it is not "useless anyway". it just contains the same dh key generated 
on package build. so each revision will contain at least a different dh 
key.
and it is well known to those following bugs and cves that nrpe got 
those issues, but the discussion has not yet reached a level where 
patches would entirely and not breaking fix that issue.
if you got any better (aka a valuable patch), provide those please 
instead of just nagging the package maintainers for things people know 
for at least 5 years already. do something about it.

>
> - Severity of this issue is "just" important, IMHO it should be grave
> (http://www.debian.org/Bugs/Developer#severities), which would also
> notify at least those using apt-listbugs.

a package should contain the upstream release source. a package should 
mostly not entirely change the mechanism of a transport layer within the 
source release, even if this is considered a security flaw. a package 
does not mean that the packager him/herself necessary needs to know how 
the upstream release is coded and how to fix bugs within them. and a 
package means that the package maintainer must decide if userprovided 
patches can be seaminglessly integrated into the package, or if he/she 
wants to wait for an upstream decision because of the severity of 
changes introduced by that patch.

mentioned bug with nrpe and ssl is such a thing and can truly understand 
that alex does not want to patch his packages when upstream source 
compiled builds behave differently.

i've already put various weekends into the icinga nrpe version and their 
patches, but currently i cannot maintain core+cgi+idoutils+mq and things 
like nrpe/nsca. that will require code, tests, and community feedback.

>
> - Of course one can argue that you cannot do much of an attack with
> NRPE, but people may rely on SSL and think it safe because of it to
> enable argument processing in NRPE

you should probably start a discussion on nagios-devel mailinglists, 
where the developers of nrpe read and write. that discussion must be 
moved upstream, and not into the package space imho.

>
>
> Cheers,
> Chris.
>
>
> _______________________________________________
> Pkg-nagios-devel mailing list
> Pkg-nagios-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nagios-devel

-- 
DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email:  michael.friedrich@univie.ac.at
phone:  +43 1 4277 14359
mobile: +43 664 60277 14359
fax:    +43 1 4277 14338
web:    http://www.univie.ac.at/zid
        http://www.aco.net

Lead Icinga Core Developer
http://www.icinga.org

[Message part 1 (text/plain, inline)]
On Mon, 2012-02-20 at 14:05 +0100, Michael Friedrich wrote:
> https://git.icinga.org/?p=icinga-nrpe.git;a=commit;h=025334c19f252f43c4ae8209ff1eec889908478b
> https://git.icinga.org/?p=icinga-nrpe.git;a=blobdiff;f=src/nrpe.c;h=1618be253465e3201ca0c988e176727f77abf8fa;hp=f5859b7a0c4c0aea7246a75fdf0d4c712106c68a;hb=025334c19f252f43c4ae8209ff1eec889908478b;hpb=b3eacf64ff33198c300f8ae72c77eedc91095093
Well but IMHO this rather solve the whole problem, just breaking with
the old code, which was useless anyway.

> > The other Nagios NRPEs (that could be used on remote host sides) which
> > still use the fake SSL?
> that code is not (yet) compatible. feel free to provide upstream patches 
> which solve that compatibility breakage problem.
I'm not sure whether there should be any desire to make anything
compatible to the old way.

I think that old design is inherently broken even if one would make the
DH params configurable (i.e. not hard coded into the code and thus
adaptable per sysadmin)... then it would have to be the same for one
icinga cluster, right?

Given that you have easily thousands of nodes,... if one of them is
compromised (or just users read the binary) they know the DH params and
could be even able to attack something.

So I guess the right way to do this is: one shared secret per nagios<->
remote host connection.

When using SSL, the certificate approach seems best to me. But I'm not
sure if this contradicts one of the main goals of NRPE (performance).

> the packaged version remains "rather useless" as the generated dh key 
> happens on configure. so installing the built binary package isn't that 
> security aware, though the source install does generate a new dh key 
> everytime you call configure. by that means, upstream probably does not 
> see the opportunity to include such patches/changes with high priority.
Well but in the real world, no one is going to compile them manually.
And still, you'd have one shared secret for the whole cluster.

> and with upstream, i do mean the official nagios nrpe project. the 
> icinga one is just an unofficial fork
What do you mean? That the Icignga NRPE is not officially distributed by
Icinga itself?

That would be bad of course :-(

> if you got any better (aka a valuable patch), provide those please 
> instead of just nagging the package maintainers for things people know 
> for at least 5 years already. do something about it.
Well it seems there are patches, which solves the issue already in a
secure way.

For the reasons I've pointed out above, I believe that the
one-set-of-DH-params per cluster is broken by design.
So while I guess that it should be fairly easy to make a patch that
simply can both (e.g. one --ssl-dh and one -ssl-certificates) option, I
don't see much reason of wasting effort into it.

> mentioned bug with nrpe and ssl is such a thing and can truly understand 
> that alex does not want to patch his packages when upstream source 
> compiled builds behave differently.
Well it really seems that at least the nagios upstream will never change
this..

> you should probably start a discussion on nagios-devel mailinglists, 
> where the developers of nrpe read and write. that discussion must be 
> moved upstream, and not into the package space imho.
Yeah you're right,... I've just commented here, as I thought it
shouldn't be much of an effort to just integrate the patch in Debians
nagios nrpe...

With respect to upstream, I personally will rather trying to contribute
to icinga (and their nrpe) if this is still necessary.
I mean as you pointed out there really is a reason why we have forks,
I'd be happy if the original nagios just dies and all folks move to the
community supported Icinga.

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]
Christoph Anton Mitterer schrieb am Monday, den 20. February 2012:

> Hi Alexander.
> 
> On Mon, 2012-02-20 at 06:29 +0100, Alexander Wirt wrote:
> > this breaks all existing nrpes
> What do you mean by breaking NRPEs? 
> The other Nagios NRPEs (that could be used on remote host sides) which
> still use the fake SSL?
SSL done right would mean that you couldn't talk with older nrpes anymore,
yes.

> But even if it does... wouldn't that be better? That SSL is just
> useless, so admins are better off with disabling it altogether.
You would lose compatbility with other distributions.

Alex

[Message part 1 (text/plain, inline)]
On Mon, 2012-02-20 at 13:58 +0100, Alexander Wirt wrote:
> SSL done right would mean that you couldn't talk with older nrpes anymore,
> yes.
So am I right, that the only way that would be accepted is basically to
allow both (i.e. --ssl-dh and --ssl-cert)?

I can't promise that I'll have time, also I'll have to look at the
Icinga NRPE first, but maybe I can put some effort into this after my
vacation.

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]
-------- Original Message  --------
Subject: Re: [Pkg-nagios-devel] Bug#547092: Bug#547092: 
nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian 
systems
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Michael Friedrich <michael.friedrich@univie.ac.at>
Date: 2012-02-20 15:31
> On Mon, 2012-02-20 at 14:05 +0100, Michael Friedrich wrote:
>> https://git.icinga.org/?p=icinga-nrpe.git;a=commit;h=025334c19f252f43c4ae8209ff1eec889908478b
>> https://git.icinga.org/?p=icinga-nrpe.git;a=blobdiff;f=src/nrpe.c;h=1618be253465e3201ca0c988e176727f77abf8fa;hp=f5859b7a0c4c0aea7246a75fdf0d4c712106c68a;hb=025334c19f252f43c4ae8209ff1eec889908478b;hpb=b3eacf64ff33198c300f8ae72c77eedc91095093
> Well but IMHO this rather solve the whole problem, just breaking with
> the old code, which was useless anyway.
<dev hat on>
the code was NOT useless. stop blaming the devs for that initial 
implementation. do better than that - actually make it better.
<dev hat off>

>
>
>>> The other Nagios NRPEs (that could be used on remote host sides) which
>>> still use the fake SSL?
>> that code is not (yet) compatible. feel free to provide upstream patches
>> which solve that compatibility breakage problem.
> I'm not sure whether there should be any desire to make anything
> compatible to the old way.

<users hat on>
why do i have to upgrade my nsclient++ server which only supports the 
old nrpe protocol? oh snap, nsclient++ dev refuses to implement the new 
nrpe protocol with ssl certs. fuck, i can't upgrade to the new version, 
but i really really want to use e.g. ipv6 layer
<users hat off>

same goes for any other addon / plugin making use of the nrpe protocol. 
break the protocol, release a new version, depend on all other devs 
wanting or willing to implement a new protocol version. hooray. got a 
solution for that problem or never thought about that why compatibility 
affects more than nrpe client and server communication?

>
> When using SSL, the certificate approach seems best to me. But I'm not
> sure if this contradicts one of the main goals of NRPE (performance).

is this just a wild guess, or on what tests are you building this thesis on?

have you ever actually tried that patch you are referring to, like you 
posted the url to?

>
>
>> the packaged version remains "rather useless" as the generated dh key
>> happens on configure. so installing the built binary package isn't that
>> security aware, though the source install does generate a new dh key
>> everytime you call configure. by that means, upstream probably does not
>> see the opportunity to include such patches/changes with high priority.
> Well but in the real world, no one is going to compile them manually.

LOL. probably you are working on the wrong support channels (if so). i 
know a lot users, who resist my advisories to use packages instead.

> And still, you'd have one shared secret for the whole cluster.

depending on the install method. you cannot guess on internal deployment 
mechanisms, that's merely different for each and everyone.

>
>
>> and with upstream, i do mean the official nagios nrpe project. the
>> icinga one is just an unofficial fork
> What do you mean? That the Icignga NRPE is not officially distributed by
> Icinga itself?

not yet. that's why you can see the git, the dev tracker, and a release 
target. but not a date nor a possible roadmap itsself.

>
> That would be bad of course :-(

sure. but if there are no maintainers who like to invest some of their 
time, it will be like that. i'll be willing to share my knowledge on 
what i've already done with it (as well as the others who provided 
patches), but then it's up to the community for now.everyone's invited 
to contribute in productive way...

>
>
>> if you got any better (aka a valuable patch), provide those please
>> instead of just nagging the package maintainers for things people know
>> for at least 5 years already. do something about it.
> Well it seems there are patches, which solves the issue already in a
> secure way.

that's still only one way to go as those patches suggest. there might be 
other ways as well (see the infamous "dont_blame_nrpe" feature. you will 
be even more shocked, when you analyse that in deep (and find possibly 
bugs on command parsing and injections *cough*).

>
> For the reasons I've pointed out above, I believe that the
> one-set-of-DH-params per cluster is broken by design.
> So while I guess that it should be fairly easy to make a patch that
> simply can both (e.g. one --ssl-dh and one -ssl-certificates) option, I
> don't see much reason of wasting effort into it.

see above, especially on the protocol note.

>
>
>> mentioned bug with nrpe and ssl is such a thing and can truly understand
>> that alex does not want to patch his packages when upstream source
>> compiled builds behave differently.
> Well it really seems that at least the nagios upstream will never change
> this..

you in person have never asked ... so far the least i haven't seen a 
question of yours on nagios-devel lists or the nrpe bug tracker.

>
>
>> you should probably start a discussion on nagios-devel mailinglists,
>> where the developers of nrpe read and write. that discussion must be
>> moved upstream, and not into the package space imho.
> Yeah you're right,... I've just commented here, as I thought it
> shouldn't be much of an effort to just integrate the patch in Debians
> nagios nrpe...

as mentioned previously, behavior changing patches will make packagers 
life hard, even harder than an actual fork keeping updated. and yes, 
integrating such a patch will most likely be a "fork" of the upstream 
releases.

>
> With respect to upstream, I personally will rather trying to contribute
> to icinga (and their nrpe) if this is still necessary.
> I mean as you pointed out there really is a reason why we have forks,
> I'd be happy if the original nagios just dies and all folks move to the
> community supported Icinga.

if you reduce the discussion level a bit (the current one is a bit 
annoying telling things we already know), and just focus on the problem 
and code, i'd love to see some input on the dev tracker. but to be fair, 
you should try it at least once on nagios-devel mailinglists, if it's 
really /dev/null or just a flamewar.

kind regards,
michael

>
>
> Cheers,
> Chris.

-- 
DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email:  michael.friedrich@univie.ac.at
phone:  +43 1 4277 14359
mobile: +43 664 60277 14359
fax:    +43 1 4277 14338
web:    http://www.univie.ac.at/zid
        http://www.aco.net

Lead Icinga Core Developer
http://www.icinga.org

[Message part 1 (text/plain, inline)]
Hey folks...

I found some time now to look into this issue again...

On Mon, 2012-02-20 at 13:58 +0100, Alexander Wirt wrote:
> SSL done right would mean that you couldn't talk with older nrpes anymore,
> yes.
...
> You would lose compatbility with other distributions.

Not necessarily... you could just switch over on both sides to the
"no-ssl" version.

For the plugin side this is easy and can be done on a per command basis,
right? So you could use no-ssl and the certficate-ssl as you like.

For the daemon side (i.e. other distros or old Debians) you could just
use start it with no-ssl.
Now you may argue that there may be several nagios/icinga servers that
use the same NRPE daemon,... and THEN one would get into troubles as
other nagioses/icingas would have to switch to no-ssl, too, which they
don't want (why??) perhaps. But even there's a easy solution, run two
nrpes on different ports.

On Mon, 2012-02-20 at 19:49 +0100, Michael Friedrich wrote:
> <dev hat on>
> the code was NOT useless. stop blaming the devs for that initial 
> implementation. do better than that - actually make it better.
> <dev hat off>
I just tried an compiled my own nrpe with different dh.h. From that one
I used the plugin with the daemon version from SUSE.
So that means plugin and daemon, each with a _DIFFERENT_ set of dh.h
parameters communicate.
And it worked just flawless, which is because anon DH is used, right?

I'm not really sure what you expect from
encryption/integrity/security/SSL but to my mind the above proves quite
clearly that the way NRPE uses SSL right now is absolutely useless,
unless you're looking for subtle ways to waste CPU power.

You must understand that the current way is not even like "one shared
secret"... it's just a unsecured (MiM-attackable) key agreement,... and
only afterwards data is encrypted.
Pointless.

> <users hat on>
> why do i have to upgrade my nsclient++ server which only supports the 
> old nrpe protocol? oh snap, nsclient++ dev refuses to implement
> the new nrpe protocol with ssl certs. fuck, i can't upgrade to the
> new version, 
> but i really really want to use e.g. ipv6 layer
> <users hat off>
That's a quite naive and stubborn way of thinking.
a) As above, users can simply deactivate ssl and everything keeps
working
b) This issue is a severe security problem. If the user want's security
(and I assume that, as he has enabled SSL) than he has probably an
interest to invest effort to get it really secure.

> same goes for any other addon / plugin making use of the
> nrpe protocol. 
> break the protocol, release a new version, depend on all other devs 
> wanting or willing to implement a new protocol version. hooray. got a 
> solution for that problem or never thought about that
> why compatibility 
> affects more than nrpe client and server communication?
In all doing respect,... I doubt you understand security... remember
when there was the SSL/TLS renegotiation flaw found in the protocol.
They had to change not only the implementations but even the protocol
itself to make it secure.
That's the way things are,... if you find out that security is not
guaranteed anymore you just have to break things if this is necessary.
Other ways you enter a funny but stupid path.

> > When using SSL, the certificate approach seems best to me. But
> > I'm not sure if this contradicts one of the main goals of
> > NRPE (performance).
> is this just a wild guess, or on what tests are you building
> this thesis on?
That was just a wild guess, I mean whether SSL with certificates would
e.g. be slower than check_by_ssh

Originally I planned to make a patch that just merges both SSL ways,...
But my tests I mentioned above seem to imply that this anon-DH thingy is
not like a one-shared-secret (or I and/or Debian would have luckily
calculated the same DH params as suse did)...
Therefore it's really pointless and I won't do this... MiM attacks are
real and you cannot just tell your attackers "please don't do it"

Now be it as it be...
I guess we can discuss about this problem forever, but in the end it
comes down to the following:

- upstream (well at least the Nagios) seem to not understand/solve (or
has the time to) this issue.

- the current way SSL is used provides little to no security at all

- there are several patches available that completely change the way SSL
is used

- these would break/remove the old way, but with little impact as users
on both sides could easily switch to the non-ssl way.

To my mind, if a upstream is dead/stubborn/unwillingly/etc. and IF there
is a patch available, than distros could and should take care on this.
It seems, the Debian Nagios Maintainers are not.

So I guess the best way now is to escalate this to the Security Team.

Comments?

Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]
Christoph Anton Mitterer schrieb am Saturday, den 17. March 2012:

> Hey folks...
> 
> 
> I found some time now to look into this issue again...
please use the icinga bugtracker.

Thanks

On 17.03.2012 17:33, Christoph Anton Mitterer wrote:
> On Mon, 2012-02-20 at 19:49 +0100, Michael Friedrich wrote:
>> <dev hat on>
>> the code was NOT useless. stop blaming the devs for that initial
>> implementation. do better than that - actually make it better.
>> <dev hat off>
> I just tried an compiled my own nrpe with different dh.h. From that one
> I used the plugin with the daemon version from SUSE.
> So that means plugin and daemon, each with a _DIFFERENT_ set of dh.h
> parameters communicate.
> And it worked just flawless, which is because anon DH is used, right?
>
> I'm not really sure what you expect from
> encryption/integrity/security/SSL but to my mind the above proves quite
> clearly that the way NRPE uses SSL right now is absolutely useless,
> unless you're looking for subtle ways to waste CPU power.
>
> You must understand that the current way is not even like "one shared
> secret"... it's just a unsecured (MiM-attackable) key agreement,... and
> only afterwards data is encrypted.
> Pointless.

so you are my teacher to tell me what to think? man, i am aware of the 
things which are wrong, but stop blaming everyone being badass and 
you're the hero of the world.
that behaviour makes your demands just pointless in regard of a valuable 
discussion. time will tell when things are to be fixed and whatnot.

>
>
>
>> <users hat on>
>> why do i have to upgrade my nsclient++ server which only supports the
>> old nrpe protocol? oh snap, nsclient++ dev refuses to implement
>> the new nrpe protocol with ssl certs. fuck, i can't upgrade to the
>> new version,
>> but i really really want to use e.g. ipv6 layer
>> <users hat off>
> That's a quite naive and stubborn way of thinking.

and? i am a user not wanting the underneath to be secure, but the 
upgrades need to run just fine.
>>
> In all doing respect,... I doubt you understand security...

you don't keep up any respect in this discussion. given that, i won't 
answer your private mail either. feel free to join the public 
discussions whenever you like, but my personal spare time won't be 
wasted by someone acting like you.

have a nice life,
michael

ps: fork your own nagios and make the world better.

As pointed out in a previous message to the bug, #547092
"nagios-nrpe-server: Insecure 'SSL' option, key identical for all
debian systems" is severity grave due to the security problem it
introduces in the service (but not critical since the problem is
limited to the nrpe service). I have adjusted it.

This bug hasn't had any activity for almost a year and was mostly
shouting before that. This package shouldn't be in testing/stable
until this is fixed lest others (as I did) spend a bunch of effort
implementing lots of nrpe based checks before realizing they just
opened a security hole on all their systems...

If this can't be solved, maybe we could recommend better
 alternatives?

Thanks,

-- 
Matt Taggart
taggart@debian.org

[Message part 1 (text/plain, inline)]
On Thu, 2013-02-07 at 14:13 -0800, Matt Taggart wrote:
> If this can't be solved, maybe we could recommend better
>  alternatives?
The better alternative is using ssh with control channel
multiplexing,... which is as fast as nrpe.

The only thing missing there was a restricted shell for the remote hosts
where they can specify white (the check commands and their args) and
blacklists (evil stuff like "*" or "..") in order to control the
commands that the monitoring node may run (as they can do on a very,
very, limited and insecure way with nrpe).

Removing nrpe from testing is IMHO a bad idea... but I would suggest to
add big fat warnings the nrpe is completely insecure.

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]
On Thu, 07 Feb 2013, Matt Taggart wrote:

> As pointed out in a previous message to the bug, #547092
> "nagios-nrpe-server: Insecure 'SSL' option, key identical for all
> debian systems" is severity grave due to the security problem it
> introduces in the service (but not critical since the problem is
> limited to the nrpe service). I have adjusted it.
> 
> This bug hasn't had any activity for almost a year and was mostly
> shouting before that. This package shouldn't be in testing/stable
> until this is fixed lest others (as I did) spend a bunch of effort
> implementing lots of nrpe based checks before realizing they just
> opened a security hole on all their systems...
> 
> If this can't be solved, maybe we could recommend better
>  alternatives?
In fact nothing is new here and security wouldn't change much with different
keys. The implementation ist just broken. But if you have an idea to improve
it, feel free to send a patch. (as long as it doesn't make nrpe incompatible
to upstreams nrpe).

Alternatives would be check_by_ssh, check_mk, snmp. There are also some nrpe
replacements flying around but I never tested one of them.

Alex

Just my 2 cents (without any hat on):

TLS integration in NRPE was broken from the beginning and more or less
by design.

The "real" and only security feature is to configure a appropriate
allowed_hosts list, which might be enough security for internal
networks in respect of TCP sessions.

Question is: Do we really want to remove NRPE from testing because of
it promising a incomplete feature?

It should be pointed out that the TLS feature is broken, but still
allowing users to use NRPE.

Because the problem is: we (Debian) might not be able to change it -
but I personally don't want users to use some self built stuff.

2013/2/7 Matt Taggart <taggart@debian.org>:
> As pointed out in a previous message to the bug, #547092
> "nagios-nrpe-server: Insecure 'SSL' option, key identical for all
> debian systems" is severity grave due to the security problem it
> introduces in the service (but not critical since the problem is
> limited to the nrpe service). I have adjusted it.
>
> This bug hasn't had any activity for almost a year and was mostly
> shouting before that. This package shouldn't be in testing/stable
> until this is fixed lest others (as I did) spend a bunch of effort
> implementing lots of nrpe based checks before realizing they just
> opened a security hole on all their systems...
>
> If this can't be solved, maybe we could recommend better
>  alternatives?

-- 
Markus Frosch
markus@lazyfrosch.de
http://www.lazyfrosch.de

On 08.02.2013 00:31, Markus Frosch wrote:
> Just my 2 cents (without any hat on):
>
> TLS integration in NRPE was broken from the beginning and more or less
> by design.
>
> The "real" and only security feature is to configure a appropriate
> allowed_hosts list, which might be enough security for internal
> networks in respect of TCP sessions.
>
> Question is: Do we really want to remove NRPE from testing because of
> it promising a incomplete feature?
>
> It should be pointed out that the TLS feature is broken, but still
> allowing users to use NRPE.
>
> Because the problem is: we (Debian) might not be able to change it -
> but I personally don't want users to use some self built stuff.

i've tried the idea of the ssl x509 patch in an unofficial nrpe fork.
lives in git here, until it dies, and will never get released, so 
beware: https://git.icinga.org/?p=icinga-irpe.git;a=summary

the nrpe implementation as is an entire mess, and one would rather 
rewrite it entirely than fix the ssl issue just for sanity. besides - 
the dh key gets generated on each configure run. so at least only the 
same package revisions share the same key.
you may figure, that not only nrpe is hard to maintain, but also nsca 
(and code wise, nagios is horrible, so is icinga 1.x).

so unless there's an idea about what to fix now or likewise, a 
maintainer capable of managing what upstream did and does wrong, there's 
not much chance to fix it. in the past you already had to fix broken 
upstream releases of nrpe/nsca/nagios and that's not really the job of a 
packager to take care of upstream's fuckups. thing is - people use and 
depend on nrpe, with or without ssl. rather then cutting that off now 
enforcing people to compile nrpe once again on their debian systems, i'd 
rather adapt the readme.

anyhow, for the alternatives - check_by_ssh or snmp. the checkmk agent 
is not capable of ssl itsself nor does it support ipv6 natively. you'd 
have to used xinetd with a ssh tunnel to make this work (and while at 
it, you could tunnel nrpe then too).

the future in icinga regards will introduce a new agent, based on the 
(already in dev) existing icinga2 message protocol (native v4/v6, x509, 
compression). but it's not yet implemented as it's planned for a later 
milestone this year.

kind regards,
Michael

-- 
DI (FH) Michael Friedrich

mail:     michael.friedrich@gmail.com
twitter:  https://twitter.com/dnsmichi
jabber:   dnsmichi@jabber.ccc.de
irc:      irc.freenode.net/icinga dnsmichi

icinga open source monitoring
position: lead core developer
url:      https://www.icinga.org

[Message part 1 (text/plain, inline)]
On Fri, 2013-02-08 at 00:26 +0100, Alexander Wirt wrote:
> In fact nothing is new here and security wouldn't change much with different
> keys. The implementation ist just broken. But if you have an idea to improve
> it, feel free to send a patch. (as long as it doesn't make nrpe incompatible
> to upstreams nrpe).
> 
> Alternatives would be check_by_ssh, check_mk, snmp. There are also some nrpe
> replacements flying around but I never tested one of them.
All agreed... but would you consider to add some big warnings about that
fact? :)

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]
[Message part 1 (text/plain, inline)]
Off topic but...

Hi Michael

On Fri, 2013-02-08 at 00:55 +0100, Michael Friedrich wrote:
> i've tried the idea of the ssl x509 patch in an unofficial nrpe fork.
> lives in git here, until it dies, and will never get released, so 
> beware: https://git.icinga.org/?p=icinga-irpe.git;a=summary
If nothing speaks against ssh (and at least the performance problems are
IMHO solved), that I would suggest that the long term plan should be to
drop any solution as NRPE.
What it does it remotely executing commands - well we already have a
protocol for that: ssh ... which supports many different auth methods
(certs, ssh keys, krb, etc.)

> the nrpe implementation as is an entire mess, and one would rather 
> rewrite it entirely than fix the ssl issue just for sanity. besides - 
> the dh key gets generated on each configure run. so at least only the 
> same package revisions share the same key.
That doesn't help,... still any other side with any other key can
connect.

> the future in icinga regards will introduce a new agent, based on the 
> (already in dev) existing icinga2 message protocol (native v4/v6, x509, 
> compression). but it's not yet implemented as it's planned for a later 
> milestone this year.
Does it give anything that ssh doesn't have?
Another protocol is just another thing to develop, maintain and another
attack target.

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]
On Fri, 08 Feb 2013, Christoph Anton Mitterer wrote:

> On Fri, 2013-02-08 at 00:26 +0100, Alexander Wirt wrote:
> > In fact nothing is new here and security wouldn't change much with different
> > keys. The implementation ist just broken. But if you have an idea to improve
> > it, feel free to send a patch. (as long as it doesn't make nrpe incompatible
> > to upstreams nrpe).
> > 
> > Alternatives would be check_by_ssh, check_mk, snmp. There are also some nrpe
> > replacements flying around but I never tested one of them.
> All agreed... but would you consider to add some big warnings about that
> fact? :)
Thats something for the release notes or readme.debian. Feel free to send a
patch. 

Alex

[Message part 1 (text/plain, inline)]
Hi Alex,

> > All agreed... but would you consider to add some big warnings about that
> > fact? :)
> Thats something for the release notes or readme.debian. Feel free to send a
> patch. 

I do not believe the issue should mean that NRPE is so critically flawed that 
it should be removed from Wheezy: as sketched there are quite some ways to use 
NRPE safely, including other ways to do encryption. Also, when not allowing 
command line parameters in the protocol (the default), for many environment 
the existing network-level safeguards and local firewalls and network acl's 
may provide adequate protection. So the key to this bug is to add 
documentation that this specific feature is not to be relied on, as you said.

I've added a patch which I think does this. It adds a warning in 
README.Debian, it rewrites the shipped SECURITY file to convert the mention of 
the facility into a warning against it, and doesn't ship the README.SSL 
anymore. I believe it should then be clear enough what the status of the 
feature is.

I don't think that adding something to the release notes is appropriate per se 
since this is not a new thing for wheezy at all.

If this can be applied in unstable/wheezy, I believe the bug can be downgraded 
to a non-RC bug about the broken functionality.

Please consider to apply and upload. I'm happy to NMU if you prefer, please 
let me know.

Cheers,
Thijs

[547092_warn.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Sun, 10 Feb 2013, Thijs Kinkhorst wrote:

> Hi Alex,
> 
> > > All agreed... but would you consider to add some big warnings about that
> > > fact? :)
> > Thats something for the release notes or readme.debian. Feel free to send a
> > patch. 
> 
> I do not believe the issue should mean that NRPE is so critically flawed that 
> it should be removed from Wheezy: as sketched there are quite some ways to use 
> NRPE safely, including other ways to do encryption. Also, when not allowing 
> command line parameters in the protocol (the default), for many environment 
> the existing network-level safeguards and local firewalls and network acl's 
> may provide adequate protection. So the key to this bug is to add 
> documentation that this specific feature is not to be relied on, as you said.
> 
> I've added a patch which I think does this. It adds a warning in 
> README.Debian, it rewrites the shipped SECURITY file to convert the mention of 
> the facility into a warning against it, and doesn't ship the README.SSL 
> anymore. I believe it should then be clear enough what the status of the 
> feature is.
> 
> I don't think that adding something to the release notes is appropriate per se 
> since this is not a new thing for wheezy at all.
> 
> If this can be applied in unstable/wheezy, I believe the bug can be downgraded 
> to a non-RC bug about the broken functionality.
> 
> Please consider to apply and upload. I'm happy to NMU if you prefer, please 
> let me know.
Thanks, that was something like I had in mind. I'll apply this patch and
upload tomorrow. 

Alex

[Message part 2 (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Sun, 10 Feb 2013, Thijs Kinkhorst wrote:

> Hi Alex,
> 
> > > All agreed... but would you consider to add some big warnings about that
> > > fact? :)
> > Thats something for the release notes or readme.debian. Feel free to send a
> > patch. 
> 
> I do not believe the issue should mean that NRPE is so critically flawed that 
> it should be removed from Wheezy: as sketched there are quite some ways to use 
> NRPE safely, including other ways to do encryption. Also, when not allowing 
> command line parameters in the protocol (the default), for many environment 
> the existing network-level safeguards and local firewalls and network acl's 
> may provide adequate protection. So the key to this bug is to add 
> documentation that this specific feature is not to be relied on, as you said.
> 
> I've added a patch which I think does this. It adds a warning in 
> README.Debian, it rewrites the shipped SECURITY file to convert the mention of 
> the facility into a warning against it, and doesn't ship the README.SSL 
> anymore. I believe it should then be clear enough what the status of the 
> feature is.
> 
> I don't think that adding something to the release notes is appropriate per se 
> since this is not a new thing for wheezy at all.
> 
> If this can be applied in unstable/wheezy, I believe the bug can be downgraded 
> to a non-RC bug about the broken functionality.
> 
> Please consider to apply and upload. I'm happy to NMU if you prefer, please 
> let me know.
And uploaded.

Thanks
Alex

[Message part 2 (application/pgp-signature, inline)]
Hi Alex, Hi Thijs

I was looking trough the bugs for nagios-nrpe, and noticed #547092
where there was an upload to address it, but the bug was not closed.

I wondered if this was intentional, als the original issue is "only"
addressed by making clear in the documentation where the issues are.

Regards,
Salvatore

On Sat, 23 Feb 2013, Salvatore Bonaccorso wrote:

> Hi Alex, Hi Thijs
> 
> I was looking trough the bugs for nagios-nrpe, and noticed #547092
> where there was an upload to address it, but the bug was not closed.
> 
> I wondered if this was intentional, als the original issue is "only"
> addressed by making clear in the documentation where the issues are.
imho the ssl is still borken, so I think the upload does not close the
problem, per se.

There is no real solution to this problem without rewriting the whole ssl
support - which makes our nrpe incompatible to the rest of the world. 

Alex

Hi Alex

On Sat, Feb 23, 2013 at 01:17:03PM +0100, Alexander Wirt wrote:
> On Sat, 23 Feb 2013, Salvatore Bonaccorso wrote:
> 
> > Hi Alex, Hi Thijs
> > 
> > I was looking trough the bugs for nagios-nrpe, and noticed #547092
> > where there was an upload to address it, but the bug was not closed.
> > 
> > I wondered if this was intentional, als the original issue is "only"
> > addressed by making clear in the documentation where the issues are.
> imho the ssl is still borken, so I think the upload does not close the
> problem, per se.
> 
> There is no real solution to this problem without rewriting the whole ssl
> support - which makes our nrpe incompatible to the rest of the world. 

Thanks. Maybe we can ask for a 'wheezy-ignore' by the release team for
this bug, with given explanation? In any case it would be good to get
the documentation update into wheezy (but this could go into testing
in one 'batch' with #701227).

Thanks a lot for your work on nagios related packages.

Regards,
Salvatore

On Sat, February 23, 2013 15:41, Salvatore Bonaccorso wrote:
> Hi Alex
>
> On Sat, Feb 23, 2013 at 01:17:03PM +0100, Alexander Wirt wrote:
>> On Sat, 23 Feb 2013, Salvatore Bonaccorso wrote:
>>
>> > Hi Alex, Hi Thijs
>> >
>> > I was looking trough the bugs for nagios-nrpe, and noticed #547092
>> > where there was an upload to address it, but the bug was not closed.
>> >
>> > I wondered if this was intentional, als the original issue is "only"
>> > addressed by making clear in the documentation where the issues are.
>> imho the ssl is still borken, so I think the upload does not close the
>> problem, per se.
>>
>> There is no real solution to this problem without rewriting the whole
>> ssl
>> support - which makes our nrpe incompatible to the rest of the world.
>
> Thanks. Maybe we can ask for a 'wheezy-ignore' by the release team for
> this bug, with given explanation? In any case it would be good to get
> the documentation update into wheezy (but this could go into testing
> in one 'batch' with #701227).
>
> Thanks a lot for your work on nagios related packages.

As explained earlier in the bug log I believe that the documentation
change is the best option we have as there's no feasible way to path the
SSL support in Debian on our own. Having the documentation fixed will warn
people against using this option and reduces this bug from RC to the
specific broken functionality.

I've asked the release team to unblock the documentation fix.

Cheers,
Thijs

Source: nagios-nrpe
Source-Version: 3.0.1-1~exp1

We believe that the bug you reported is fixed in the latest version of
nagios-nrpe, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 547092@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bas Couwenberg <sebastic@debian.org> (supplier of updated nagios-nrpe package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sun, 04 Dec 2016 18:36:54 +0100
Source: nagios-nrpe
Binary: nagios-nrpe-server nagios-nrpe-plugin
Architecture: source amd64
Version: 3.0.1-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian Nagios Maintainer Group <pkg-nagios-devel@lists.alioth.debian.org>
Changed-By: Bas Couwenberg <sebastic@debian.org>
Description:
 nagios-nrpe-plugin - Nagios Remote Plugin Executor Plugin
 nagios-nrpe-server - Nagios Remote Plugin Executor Server
Closes: 547092 660583 662247 662249 728218 755507 756410 756414 773441 775924 834857 843805
Changes:
 nagios-nrpe (3.0.1-1~exp1) experimental; urgency=medium
 .
   [ Alexander Wirt ]
   * Sync uploaders with reality.
     (closes: #773441)
 .
   [ Bas Couwenberg ]
   * New upstream release.
     - Reworked SSL/TLS. See the README.SSL.md file for full info.
     (closes: #547092)
   * Add myself to Uploaders.
   * Add Vcs-* fields to control file.
     (closes: #755507)
   * Change nagios-plugins dependencies to monitoring-plugins.
   * Switch from dpatch to source format 3.0 (quilt).
     (closes: #756410)
   * Drop obsolete patch: 04_weird_output.dpatch.
   * Restructure control file with cme.
   * Reorder (build) dependencies.
   * Add Homepage field to control file.
   * Update copyright file using copyright-format 1.0.
   * Add gbp.conf to use pristine-tar by default.
   * Update build dependency to use openssl 1.0.
   * Enable all hardening buildflags.
     (closes: #728218)
   * Enable parallel builds.
   * Suggest xinetd | inetd.
     (closes: #662247)
   * Include PDF & ODT documentation in docs.
     (closes: #662249)
   * Update watch file to handle common issues.
   * Add upstream metadata.
   * Merge nrpe.cfg patches into single patch.
     (closes: #660583)
   * Use configure option to set custom PID directory instead of patch.
   * Drop 09_noremove_pid.patch, fixed upstream. Refresh remaining patches.
   * Add patch to use pre-generated dh.h for reproducible builds.
   * Override dh_auto_build to build all targets.
   * Use dh-autoreconf instead of autotools-dev.
   * Use exit status 0 in init script when inetd is configured.
     (closes: #775924)
   * Include README.SSL.md in docs.
   * Bump Standards-Version to 3.9.8, changes:
     Vcs-* fields, copyright-format 1.0.
 .
   [ Benjamin Drung ]
   * Use dh_auto_configure to enable default hardening flags.
     (closes: #843805)
   * Fix copyright-refers-to-symlink-license.
     (closes: #756414)
 .
   [ Chris Lamb ]
   * Make the build reproducible.
     (closes: #834857)
Checksums-Sha1:
 8cc57beb3cb67ef9deb3546042fd281b72f9f50c 2102 nagios-nrpe_3.0.1-1~exp1.dsc
 e2b79bba41b1198c9d3dec0c559fc932fb12a429 514097 nagios-nrpe_3.0.1.orig.tar.gz
 912e6cdf82213a9a9559a0b2aeee134e62ff95f8 12736 nagios-nrpe_3.0.1-1~exp1.debian.tar.xz
 0bd6eea3f01b4f464eef9bc45ec8a7c8dbf8b705 53366 nagios-nrpe-plugin-dbgsym_3.0.1-1~exp1_amd64.deb
 4a286c3cef3ddc1acc9b7baab199133d7508bd00 29254 nagios-nrpe-plugin_3.0.1-1~exp1_amd64.deb
 bc0128fb2be0af50dccb36584192041edb9a006a 72952 nagios-nrpe-server-dbgsym_3.0.1-1~exp1_amd64.deb
 e4e6d6599413de839f8b18580c1deafdb8c97da5 345136 nagios-nrpe-server_3.0.1-1~exp1_amd64.deb
 f6038221d886eb3cf49294aff0e5b41b7133163c 6081 nagios-nrpe_3.0.1-1~exp1_amd64.buildinfo
Checksums-Sha256:
 063453ab1983f4676755222baf0580fba1be311cccf69448a25973dd2e3a3e7a 2102 nagios-nrpe_3.0.1-1~exp1.dsc
 8f56da2d74f6beca1a04fe04ead84427e582b9bb88611e04e290f59617ca3ea3 514097 nagios-nrpe_3.0.1.orig.tar.gz
 cca437bf8eecf71d9baca79bd8c5e9deeac5b4a883e00901228fff5ff5040f65 12736 nagios-nrpe_3.0.1-1~exp1.debian.tar.xz
 c9fecfef407d434cb126ff0a860afeca5b4e686a3ef00c068b05da4de0882717 53366 nagios-nrpe-plugin-dbgsym_3.0.1-1~exp1_amd64.deb
 6adc4c684c943f03032addeb461bdb7e27a84675d1b16f4882fcdad82744efd9 29254 nagios-nrpe-plugin_3.0.1-1~exp1_amd64.deb
 3bbbfb797e1465956ebc99dd392e16fa489c284180968663ecebdab67caec180 72952 nagios-nrpe-server-dbgsym_3.0.1-1~exp1_amd64.deb
 914e5665f4bee19d99f0a3e6efea1bdf5aa50e39478c1083ecbb26bec9d70293 345136 nagios-nrpe-server_3.0.1-1~exp1_amd64.deb
 6177b27184012765c4f4e7682fef0edcca309109efd5e23c8a484c2445696f04 6081 nagios-nrpe_3.0.1-1~exp1_amd64.buildinfo
Files:
 c3f8a9a9c05a6b8b810c977e569186b0 2102 net optional nagios-nrpe_3.0.1-1~exp1.dsc
 8c81f251d9ee0903e5ff0191e99f7981 514097 net optional nagios-nrpe_3.0.1.orig.tar.gz
 10b7bfe2e0a2a30c895f773ad50fd203 12736 net optional nagios-nrpe_3.0.1-1~exp1.debian.tar.xz
 5daff3dd0ffcf1997d77be09614f3355 53366 debug extra nagios-nrpe-plugin-dbgsym_3.0.1-1~exp1_amd64.deb
 bfaa2dc3ee62894ffb3edbedf5ddab7c 29254 net optional nagios-nrpe-plugin_3.0.1-1~exp1_amd64.deb
 319c915240286dee87629e07c0d48ab5 72952 debug extra nagios-nrpe-server-dbgsym_3.0.1-1~exp1_amd64.deb
 958f74614dae92a01b634331c7154568 345136 net optional nagios-nrpe-server_3.0.1-1~exp1_amd64.deb
 1857c951ceef5ca2a30bdae4bc1ebe8d 6081 net optional nagios-nrpe_3.0.1-1~exp1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJYRFgGAAoJEGdQ8QrojUrxUFEP/1RU25K2El7YtGn+djZohFPO
bLrGDcY5p2TW13iSmNUXb2ThmCz8pt8fGsIlOAt6C8GpczgwzjpSmvJwkFrrCe8k
r+D+/v5xZb/8JkrMjmxpv2NNBE+8noO96YjWdAq6gQbX9D+L1a0iev7KR57ZkNu1
wbRcESkqRDo0cV+pAg1z0Rj6ae9D5CiHuGoino2cOes20FRDNvr2jIf3dBs5ItO8
wRoch+3fK0AOHuHZRRygAbRIDgkc+zO9TEzoIHhRyM9vDni1ANwz5ii1gorDLj8N
1Ryk4U2ZHCzZJuUWV9bsril5N06z8Zmy2p8UkBHq90gaUAWXy2IRiF24UIyQAd6T
o+BtrVGgOahCnxNyAijBW1ta+AfxcL1AjQ30s54WILebZ9YmYNa3UvRAnxynWx4o
l2MaOY/ljnsyDl26EfoRzIRjFpROeudd+KuEpdgaoodAzjHiI5B1jDC/esoMZ3tb
k/huvUOT+H64Bd11Hc1vpSE86XqFo5gKaJ1wQBvJybMfXeG+ZGNxjfsU7XMYczJx
rxSCLFw40s8+L88OSN5RscTjupdDh3ase08SC1zbPf7pIMzjLLO5jR3nugBc0tq6
7HppQ+oYSLVW1Eo/iWaAnjvJI8TsuBeRN5bWC1DfeAlDSbWUD8UBR95rnXWV/eMX
Ba+zNgS0KNkYhiWCxXdB
=8ZLb
-----END PGP SIGNATURE-----

[Message part 1 (text/plain, inline)]
Dear Customer,

We can not deliver your parcel arrived at January 24.

You can download the shipment label attached!

Yours faithfully,

Leon Herring,

USPS Senior Support Manager.

[Delivery-Receipt-41255711170.zip (application/zip, attachment)]

Debian Bug report logs - #547092 nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian systems

Debian Bug report logs - #547092
nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian systems