www.cendio.com
Bug 5171 - tlstunnel doesn't understand SSLv2 handshakes
: tlstunnel doesn't understand SSLv2 handshakes
Status: CLOSED FIXED
: ThinLinc
Misc
: 4.2.0
: PC Unknown
: P2 Normal
: 4.3.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2014-05-28 13:20 by
Modified: 2014-10-14 13:40 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2014-05-28 13:20:57
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".
------- Comment #2 From cendio 2014-07-24 11:45:49 -------
Fixed in r29217.

Tester needs to test with all SSL/TLS versions, as well as unencrypted.
Preferably also test with several SSL implementations.
------- Comment #3 From cendio 2014-10-09 09:51:54 -------
(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.
------- Comment #4 From cendio 2014-10-14 13:40:18 -------
(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