check_http - SSLv3 forced even when the --ssl flag = 1.

[biox]

I'm getting check_http service errors to most of my webservers that do not have SSLv3 enabled.

# /usr/local/nagios/libexec/check_http -H XXXX --ssl=1
CRITICAL - Cannot make SSL connection.
139714506594240:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert
handshake failure:s3_pkt.c:1259:SSL alert number 40

As you can see, even when I explicitly force TLSv1, it still attempts
sslv3.

Here's the nmap scan showing the ciphers available on my webserver:

nmap --script ssl-enum-ciphers -p 443 XXXX

Starting Nmap 6.47 ( http://nmap.org ) at 2016-02-13 18:46 CST
Nmap scan report for XXXX (140.32.112.244)
Host is up (0.00094s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|     compressors:
|       NULL
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds

[jahunter]

This is a serious bug. Is no one looking at this?

[tmcnag]

Please note that this is a community-driven open-source project. While we do have paid developers on-staff, it is not always possible to address every issue as a priority. We welcome contributions in the form of pull requests for issues such as these. Barring that, the best I can do is ask our in-house C dev to look into this and put the rest of his work on-hold.

[jahunter]

Hi Trevor, I appreciate the situation but this is a pretty serious bug, especially now that many people have disabled SSLv3, so any urgency you can attach to this would be much appreciated. Thanks for responding so promptly.

[mguthrie88]

This will affect a LOT of AWS related sites, including S3, CloudFront, and Lambda functions. We need this fixed in order for Nagios to be a viable option for our AWS resources. Even though Nagios plugins are community maintained, this will make the website monitor in Nagios XI useless against a lot of AWS endpoints.

[jfrickson]

For anyone having this problem: please post the version of nagios plugins you are using, and the version of openssl. There have been reports that a newer version of openssl is needed.

[Imprecator]

Hello,
I just ran into this problem. I am using check_http from monitoring-plugins.org version 2.1.2.
I presume it's a fork from your project (or the other way around) since the error is exactly the same.
I had originally compiled it with OpenSSL 0.9.8e-fips-rhel5 (which comes standard with RHEL5).
Once I recompiled with OpenSSL 1.0.0k the problem went away. So the reports you're getting seem to be true.

[jfrickson]

Per @Imprecator 's comment above, and no other responses, I'm assuming the older openssl is the problem and am closing this issue.

[dnorth98]

I'm not sure (yet!) it is the openssl version. This is on centos 7:

openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

./check_http --version
check_http v2.1.2 (nagios-plugins 2.1.2)

So, the version of openssl is > 1.0.0k (which seemed to resolve the issue above). I've just re-pulled all of the plugins and recompiled but I seem to get the same problem.

[Imprecator]

Very odd, I'm using Centos 5 and tried OpenSSL 1.0.1e 11 Feb 2013 (downloaded from https://www-origin.openssl.org/source/old/1.0.1/ ) works fine

[xurizaemon]

FWIW, observing this with OpenSSL 1.0.1e and an older check_http v1.4.15

$ /usr/lib/nagios/plugins/check_http -V
check_http v1.4.15 (nagios-plugins 1.4.15)
$ openssl version
OpenSSL 1.0.1e 11 Feb 2013

Example -

$ /usr/lib/nagios/plugins/check_http -H www.greeninstitute.org.au -t 30 -w 7 -c 14 -k "Cookie: donotcache=1" --ssl
CRITICAL - Cannot make SSL connection
9266:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:607:
 HTTP CRITICAL - Error on receive

Yes that's nagios-plugins from obsolete Debian Squeeze, posting to confirm this can happen with OpenSSL 1.0.1e :)

[jfrickson]

Re-opening the issue, since there are still problems.
I'll try to duplicate the problem here.

[jfrickson]

Just coming back to this. @dnorth98 have you tried any openssl version greater than 1.0.1e? Maybe try with 1.0.1s or 1.0.1t.

[xurizaemon]

I addressed our issues with Debian Squeeze by swapping in the binary from Debian's monitoring-plugins for Wheezy. (I know and accept the risks here.)

Thought this also may be useful - while --ssl=1 didn't help us, --ssl --sni did.

$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
$ ./check_http -V
check_http v2.1.1 (monitoring-plugins 2.1.1)

$ ./check_http -H www.greeninstitute.org.au -t 30 -w 7 -c 14 -k "Cookie: donotcache=1" --ssl=1
CRITICAL - Cannot make SSL connection.
4147955336:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error:s3_pkt.c:1261:SSL alert number 80

$ ./check_http -H www.greeninstitute.org.au -t 30 -w 7 -c 14 -k "Cookie: donotcache=1" --sni --ssl
HTTP OK: HTTP/1.1 200 OK - 69525 bytes in 0.031 second response time |time=0.030645s;7.000000;14.000000;0.000000 size=69525B;;;0

(Not posting to request support, just to provide info for others who run into this. Sorry for noise if this isn't helpful to you.)

[estroh]

observing the same issue on Redhat 6.8 server connecting to a Wildfly 8.2 instance after enforcing TLS1.1+

$ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
$ /usr/lib64/nagios/plugins/check_http -V
check_http v2.0.3 (nagios-plugins 2.0.3)

The result is sporadic. About 50% of all requests show alert number 40

$ /usr/lib64/nagios/plugins/check_http -H hostname.lcl -u / -p 8443
HTTP OK: HTTP/1.1 200 OK - 3103 bytes in 0.071 second response time |time=0.071374s;;;0.000000 size=3103B;;;0
$ /usr/lib64/nagios/plugins/check_http -H hostname.lcl -u / -p 8443 
CRITICAL - Cannot make SSL connection.
140018681005928:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1259:SSL alert number 40

Im observing the same issue on using "wget --no-check-certificate"

OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Unable to establish SSL connection.

[masterob1]

We also found this problem on redhat 5.7 and centos 6.7-6.8. This problem is occured from cipher suit. Currently, openssl 0.98 is not work

[hfinucane]

I just went through debugging this against an AWS Cloudfront host, and it turns out that some newer web servers require SNI, and unlike web browsers, check_http and openssl s_client don't do that automatically. You can make things work by adding --sni to your check_http arguments. See http://security.stackexchange.com/a/102018/125206 for a more thorough explanation.

[jfrickson]

Nobody has come up with an example of it failing with a version of OpenSSL greater than 1.0.1e. It looks like something greater than 1.0.1e and/or using --sni fixes the problem. Closing.

[fstanchina]

I'm getting this error on my monitoring server running Debian "stretch" amd64, either with check_http from the monitoring-plugins package or with the version included in the OMD 2.60 package. Both are version 2.2, the OpenSSL library is 1.1.0f-3+deb9u1 (libssl 1.0.2l-2+deb9u2 is also installed on this system, but I've verified with ldd that both check_http binaries are using 1.1).

Only some host checks are failing, notably towards Windows Server 2003 servers (yes, I'm going to get rid of these soon!) and on HP iLO3 management ports. An example:

# /opt/omd/versions/2.60-labs-edition/lib/nagios/plugins/check_http -v -v -v -H ilocz2045hgrz -C30
CRITICAL - Cannot make SSL connection.
140121033565952:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1399:SSL alert number 40
SSL initialized

OpenSSL only supports TLS here, it appears. If I use option -S3, I get:
UNKNOWN - SSL protocol version 3 is not supported by your SSL library.

Using --sni doesn't make any difference.

The host supports SSLv3, TLSv1 and TLSv1.1; openssl s_client connects without trouble. I can attach a nmap scan if you think it could be useful.

This is a new install on amd64 because OMD version 2.60 doesn't support i386 any more; the old monitoring server running OMD 2.10 has no problem doing the checks with check_http v2.1.1 and OpenSSL 1.0.1t-1+deb8u7.