Nagios Tracker - 0000125: nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian systems

Notes
(0000279) davegarvey (reporter) 2011-05-04 14:13	I am very excited about zulcss patch and findings. Please fix...

(0000382) calestyo (reporter) 2012-03-18 21:03	This bug is related/duplicate to bug 0000090, can someone with the appropriate rights set the relationship? :)

(0000383) calestyo (reporter) 2012-03-18 21:23	Some side notes from my site: I recently tried to discuss this downstream at Debian, with basically just obstacles but no success. I strongly wonder why Nagios doesn't apply this patch, or the one in bug 0000090. Currently, SSL in NRPE is absolutely useless (unless you consider wasting CPU cycles usefulness). Compiling the packages with one’s own DH parameters doesn’t make it secure at all. It's still anon-DH and you can connect to just any NRPE that you can reach. So it's not like secure with one-shared-secret. The only "argument" that speaks against removing the current SSL usage and replacing it by something better[0] is that people think it would break compatibility. This is just not true. Why? If you have a homogeneous setup with then all fixed NRPE clients/servers, you're save anyway. If not, you can still simply disable (the old) SSL. And you can do this on a per-host basis. Just define a check_by_nrpe and check_by_nrpe_no_ssl command and use it depending on whether the remote host is already fixed or still vulnerable. On the remote side(s), either just disable the SSL in the NRPE daemon. You won't loose a single bit of security but actually you'll gain CPU resources. In the unlikely case, that the remote host is monitored by different check_by_nrpes, where one is already fixed and one still vulnerable and you cannot tell the vulnerable side to upgrade... simply run two NRPE daemons on different ports. As you can see, no real compatibility breakage (even in the most obscure setups), just a tiny bit of work that is simply required in order to become secure and have this issue fixed. So again, please have a look at this issue and decide, and don't let it sleep here for ever :-) Cheers, Chris.

Issue History
Date Modified	Username	Field	Change
2010-01-11 09:59	zulcss	New Issue
2010-01-11 09:59	zulcss	File Added: fullssl.patch
2010-01-11 09:59	zulcss	OS	=> Linux
2010-01-11 09:59	zulcss	OS Version	=> Ubuntu/Debian
2011-05-04 14:13	davegarvey	Note Added: 0000279
2011-05-04 14:13	davegarvey	Issue Monitored: davegarvey
2012-03-18 21:02	calestyo	Issue Monitored: calestyo
2012-03-18 21:03	calestyo	Note Added: 0000382
2012-03-18 21:23	calestyo	Note Added: 0000383

Relationships