local error: tls: bad record MAC #2

New issue

Closed

opened 2021-10-29 16:19:30 +02:00 by sf · 3 comments

sf commented

2021-10-29 16:19:30 +02:00

Owner

When go-nrpe is newer them receiver (deb11 vs. deb10) I get

Oct 29 16:09:00 vsrv75581 nrpe[3885131]: short read remote=[2a01:xxx:xxx:xxxx::xxx]:55864: local error: tls: bad record MAC

It seems to be a problem with different TLS versions (when you ask google).
So is there a way to force the TLS version?

When go-nrpe is newer them receiver (deb11 vs. deb10) I get ``` Oct 29 16:09:00 vsrv75581 nrpe[3885131]: short read remote=[2a01:xxx:xxx:xxxx::xxx]:55864: local error: tls: bad record MAC ``` It seems to be a problem with different TLS versions (when you ask google). So is there a way to force the TLS version?

heiko added the

bug

label

2021-10-31 08:33:17 +01:00

heiko commented

2021-10-31 13:44:05 +01:00

Owner

Is there a reproducer in our environment?

sf commented

2021-11-01 09:07:47 +01:00

Author

Owner

At the CM network. More infos at the office.

heiko added

wontfix

and removed

bug

labels

2021-11-02 08:21:53 +01:00

heiko commented

2021-11-02 08:26:41 +01:00

Owner

This is beyond the use case of go-NRPE.

It was designed to enable an ancient Nagios check_nrpe connecting to newer systems. The ancient check_nrpe wasn't able to communicate with recent nrped, so Go-NRPE provides kind of backward compatibility and should be removed as soon as the Nagios check_nrpe is recent enough.

The described issue happens if an new check_nrpe talks to the backward compatible go-NRPE. The go-NRPE uses a hardwired self-signed certificate, which makes the new check_nrpe unhappy. check_nrpe drops the connection than and go-NRPE logs this dropped connection and its side-effects.

While we could implement using a valid X509 certificate for go-NRPE, that's beyond the scope, as newer NRPE daemons provide all that functionality and even more.

This is beyond the use case of go-NRPE. It was designed to enable an ancient Nagios `check_nrpe` connecting to newer systems. The ancient `check_nrpe` wasn't able to communicate with recent `nrped`, so Go-NRPE provides kind of backward compatibility and should be removed as soon as the Nagios `check_nrpe` is recent enough. The described issue happens if an new `check_nrpe` talks to the _backward compatible_ go-NRPE. The go-NRPE uses a hardwired self-signed certificate, which makes the new `check_nrpe` unhappy. `check_nrpe` drops the connection than and go-NRPE logs this dropped connection and its side-effects. While we could implement using a valid X509 certificate for go-NRPE, that's beyond the scope, as newer NRPE daemons provide all that functionality and even more.

heiko closed this issue

2021-11-02 08:26:42 +01:00