Windows – Bug setting up stunnel server: `SSL3_GET_CLIENT_HELLO:wrong version number`

httpssslstunnelwindows

I'm setting up an stunnel server on Windows XP, and I get this bug when a client tries to access:

2013.02.14 00:02:16 LOG7[8848:7664]: Service [https] accepted (FD=320) from 107.20.36.147:56160
2013.02.14 00:02:16 LOG7[8848:7664]: Creating a new thread
2013.02.14 00:02:16 LOG7[8848:7664]: New thread created
2013.02.14 00:02:16 LOG7[8848:9792]: Service [https] started
2013.02.14 00:02:16 LOG5[8848:9792]: Service [https] accepted connection from 107.20.36.147:56160
2013.02.14 00:02:16 LOG7[8848:9792]: SSL state (accept): before/accept initialization
2013.02.14 00:02:16 LOG7[8848:9792]: SSL alert (write): fatal: handshake failure
2013.02.14 00:02:16 LOG3[8848:9792]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2013.02.14 00:02:16 LOG5[8848:9792]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2013.02.14 00:02:16 LOG7[8848:9792]: Local socket (FD=320) closed
2013.02.14 00:02:16 LOG7[8848:9792]: Service [https] finished (0 left)

Any idea what to do about this? I read online that this might mean that my server is advertising that it can communicate in SSL3 but it in fact can't. If this is true I'd like to know how I can fix this. I'm editing the stunnel.conf file but I have no idea what to change in it to fix this.

UPDATE:

The above error message shows only when the Twilio client (i.e. Twilio's server) tries to access my server. When I try to access my server with one of my computers, the page does show up, but after the contents show up, Chrome shows the page as "loading" for around 30 seconds, at the end of which stunnel gives this message:

transfer: s_poll_wait: TIMEOUTclose exceeded: closing

UPDATE:

Here is the wireshark capture: https://gist.github.com/cool-RR/4963477

Cap file: https://dl.dropbox.com/u/1927707/wireshark.cap

Note that the server runs on port 8088.

UPDATE:

Here is the log from the server (with debug=7):

2013.02.17 17:06:52 LOG7[7636:2092]: No limit detected for the number of clients
2013.02.17 17:06:52 LOG5[7636:2092]: stunnel 4.54 on x86-pc-msvc-1500 platform
2013.02.17 17:06:52 LOG5[7636:2092]: Compiled/running with OpenSSL 1.0.1c-fips 10 May 2012
2013.02.17 17:06:52 LOG5[7636:2092]: Threading:WIN32 SSL:+ENGINE+OCSP+FIPS Auth:none Sockets:SELECT+IPv6
2013.02.17 17:06:52 LOG5[7636:2092]: Reading configuration from file stunnel.conf
2013.02.17 17:06:52 LOG5[7636:2092]: FIPS mode is enabled
2013.02.17 17:06:52 LOG7[7636:2092]: Compression not enabled
2013.02.17 17:06:52 LOG7[7636:2092]: Snagged 64 random bytes from C:\Documents and Settings\User/.rnd
2013.02.17 17:06:52 LOG7[7636:2092]: Wrote 1024 new random bytes to C:\Documents and Settings\User/.rnd
2013.02.17 17:06:52 LOG7[7636:2092]: PRNG seeded successfully
2013.02.17 17:06:52 LOG6[7636:2092]: Initializing service [https]
2013.02.17 17:06:52 LOG7[7636:2092]: Certificate: G:\Dropbox\StartSSL\SSL Cert.pem
2013.02.17 17:06:52 LOG7[7636:2092]: Certificate loaded
2013.02.17 17:06:52 LOG7[7636:2092]: Key file: G:\Dropbox\StartSSL\SSL Cert.pem
2013.02.17 17:06:52 LOG7[7636:2092]: Private key loaded
2013.02.17 17:06:52 LOG7[7636:2092]: Could not load DH parameters from G:\Dropbox\StartSSL\SSL Cert.pem
2013.02.17 17:06:52 LOG7[7636:2092]: Using hardcoded DH parameters
2013.02.17 17:06:52 LOG7[7636:2092]: DH initialized with 2048-bit key
2013.02.17 17:06:52 LOG7[7636:2092]: ECDH initialized with curve prime256v1
2013.02.17 17:06:52 LOG7[7636:2092]: SSL options set: 0x03000004
2013.02.17 17:06:52 LOG5[7636:2092]: Configuration successful
2013.02.17 17:06:52 LOG7[7636:2092]: Service [https] (FD=268) bound to 0.0.0.0:8088
2013.02.17 17:07:08 LOG7[7636:2092]: Service [https] accepted (FD=320) from 54.242.25.199:45922
2013.02.17 17:07:08 LOG7[7636:2092]: Creating a new thread
2013.02.17 17:07:08 LOG7[7636:2092]: New thread created
2013.02.17 17:07:08 LOG7[7636:8004]: Service [https] started
2013.02.17 17:07:08 LOG5[7636:8004]: Service [https] accepted connection from 54.242.25.199:45922
2013.02.17 17:07:08 LOG7[7636:8004]: SSL state (accept): before/accept initialization
2013.02.17 17:07:08 LOG7[7636:8004]: SSL alert (write): fatal: handshake failure
2013.02.17 17:07:08 LOG3[7636:8004]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2013.02.17 17:07:08 LOG5[7636:8004]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2013.02.17 17:07:08 LOG7[7636:8004]: Local socket (FD=320) closed
2013.02.17 17:07:08 LOG7[7636:8004]: Service [https] finished (0 left)

UPDATE:

Here's my stunnel.conf file.

Best Answer

You should make a network capture and see why it was rejected. Also check the logs on both end points. Increase the debug level in the stunnel conf.

You need to make a network trace to figure out which version of the SSL protocol the client is supporting. Then make sure the your server supports that version too.

A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested CipherSuites and suggested compression methods.

Source

Please note that the SSL protocol was changed a few years ago because of a security bug in the renegotiation. See CVE-2009-3555 and this page on SSL Renegotiation

The server is responding with:

Secure Sockets Layer
    SSLv3 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
        Content Type: Alert (21)
        Version: SSL 3.0 (0x0300)
        Length: 2
        Alert Message
            Level: Fatal (2)
            Description: Handshake Failure (40)

You have to check the logs on the SSL server to see why it has refused the connection. Try to enable SSL debugging on stunnel with: debug=7.

The stunnel server has options = NO_SSLv3, but the client is trying to connect using SSLv3. You need to upgrade the client to support a newer version of SSL or you need to change the stunnel configuration to accept SSLv3.

Related Solutions

Ssl – HTTPS Stunnel and Haproxy

The application session is typically stored as a cookie. There are a number of important components in a cookie but the relevant one in this case is the secure flag in the cookie.

It is possible for the cookie to get lost when you move from https to http because if the secure flag is set then the cookie will not be sent under a non-https connection.

You need to check to see what is happening to the cookies. You can do this easily by using suitable browser tools and extensions to inspect the cookies.

Ssl – haproxy + stunnel + keep-alive

This is about HTTP keep-alive, which allows for multiple resource requests to come through a single TCP session (and, with SSL, a single SSL session). This is of great importance to the performance of an SSL site, as without keep-alive, an SSL handshake would be needed for each requested resource.

So, the concern here is one big keep-alive session from the client all the way to the backend server. It's an important thing for performance, and taken as a matter of course for modern HTTP servers, but this patch says it doesn't support it. Let's look into why..

A keep-alive session is just more requests one after another - once the server finishes its response to one request, the server doesn't sent a FIN packet to end the TCP session; the client can simply send another batch of headers.

To understand what that patch is doing, here's an example of a keep-alive conversation:

Client:

GET / HTTP/1.1
Connection: keep-alive
Host: domain.com
...

Server:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Apache
Content-Length: 34
.... (other headers)
<html><head>content!</head></html>

Here's where a non-keep-alive connection would stop. But, keep-alive allows the client to just fire off another:

GET /images/some/image.on.the.page.jpg HTTP/1.1
Connection: keep-alive
Host: domain.com
...

For client ID in proxying, some reverse proxies can add in the X-Forwarded-For header in each client request. That tells the upstream server where the request is coming from (instead of every request initiating from the reverse proxy's IP), for sanity in logging and other application needs.

The X-Forwarded-For header needs to be injected into each and every client resource request sent through the keep-alive connection, as the full headers are sent each time; handling of the X-Forwarded-For header and translation into it being the "real" request IP is done on a per-request, not per-TCP-keep-alive-session, basis. And hey, maybe there's some awesome reverse proxy software out there that uses a single keep-alive session to service requests from multiple clients.

This is where this patch fails.

The patch at that site watches the TCP session's buffer for the end of the first set of HTTP headers in the stream, and injects the new header into the stream after the end of that first set of headers. After this is done, it considers the X-Forwarded-For job done, and stops scanning for the end of new sets of headers. This method has no awareness of all of future headers coming in via subsequent requests.

Can't really blame them; stunnel wasn't really built to do handling and translation of the contents of its streams.

The effect that this would have on your system is that the first request of a keep-alive stream will get the X-Forwarded-For header injected properly, and all of the subsequent requests will work just fine - but they won't have the header.

Unless there's another header injection patch out there that can handle multiple client requests per connection (or get this one tweaked with the help of our friends over at Stack Overflow), you may need to look at other options for your SSL termination.

Best Answer

Related Solutions

Ssl – HTTPS Stunnel and Haproxy

Ssl – haproxy + stunnel + keep-alive

Related Topic