We've had problems with Nagios on RHEL 5 not being able to connect to tlwebaccess for monitoring purposes. Troubleshooting time! GnuTLS comes with a gnutls-serv utility that sets up a TLS server, so lets try use that one to see if this is a flaw in our GnuTLS. > $ cbrun x86_64 gnutls-serv --x509certfile=server.crt --x509keyfile=server.key We'll then try to connect to that server from the RHEL 5 machine. We'll use openssl s_client because it's the closest thing to a nagios-plugins check_foo program we can get that also allows us to control how we connect. > [root@server ~]$ openssl s_client -connect aperture.lkpg.cendio.se:5556 > [...] > New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Works just great, so our GnuTLS can obviously handle the handshaking part. I want to be really sure though, so lets try again, but with only SSLv2. > [root@trotsky ~]# openssl s_client -connect aperture.lkpg.cendio.se:5556 -ssl2 > CONNECTED(00000003) > 24470:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:427: This results in a handshake failure, which is the expected error you'd get when trying to connect using SSLv2 to a server that doesn't support it. So GnuTLS in itself seems to handle everything just fine. With that out of the way, lets try connecting to tlstunnel: > [root@trotsky ~]# openssl s_client -connect aperture.lkpg.cendio.se:300 > CONNECTED(00000003) > 25192:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:588: That is a different error message than the handshake failure above. A look at the log file presents this: > 2014-05-28 12:48:11 INFO tlwebaccess[27593]: Connection from 2a00:801:107:4700:20f:1fff:fe69:c463, port 50496 > 2014-05-28 12:48:12 ERROR tlwebaccess[27596]: code 400, message Bad HTTP/0.9 request type ('\x80w\x01\x03\x01\x00N\x00\x00\x00') > 2014-05-28 12:48:12 INFO tlwebaccess[27596]: '\x80w\x01\x03\x01\x00N\x00\x00\x00 \x00\x009\x00\x008\x00\x005\x00\x00\x16\x00\x00\x13\x00\x00' 400 - If you look closely, you'll see that the PIDs differ, which means that tlstunnel actually passes this data on to tlwebaccess, which predictably pukes on it since it's not HTTP. Turns out tlstunnel only understands SSLv3 or TLSv1 handshakes, so it believes that this is a plain-text connection and passes the data along on the plain-text socket instead of understanding the handshake and saying "No, SSLv2 isn't supported".
Fixed in r29217. Tester needs to test with all SSL/TLS versions, as well as unencrypted. Preferably also test with several SSL implementations.
(In reply to comment #2) > Fixed in r29217. > > Tester needs to test with all SSL/TLS versions, as well as unencrypted. > Preferably also test with several SSL implementations. I've replaced the tlstunnel binary on eudemo, which fixed the Nagios warning. So this problem is indeed fixed. Testing the other cases remains.
(In reply to comment #2) > Fixed in r29217. > > Tester needs to test with all SSL/TLS versions, as well as unencrypted. > Preferably also test with several SSL implementations. Works fine. Tested: * http redirection using Firefox * https using Firefox * openssl s_client * openssl s_client -ssl2 * openssl s_client -ssl3 * wget * lynx
