WARNING: SSLv3 is obsolete. Consider disabling it altogether.

I'm trying to set up Stunnel to server as SSL cache. Everything was smooth, and mostly it works as designed.

Then I encountered errors in log files:

 SSL_accept: 1408F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Not all clients trigger that, for some strange reason. Connecting from CentOS using links - error shows up (tried multiple machines). Connecting from Ubuntu using links - no error.

Tried using wget, and all is smooth with TLSv1, but error shows up with SSLv3. At the same time, wget reports:

OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Unable to establish SSL connection.

Here is my config:

pid = /etc/stunnel/stunnel.pid
debug = 3
output = /etc/stunnel/stunnel.log

socket=l:TCP_NODELAY=1
socket=r:TCP_NODELAY=1

verify=3    

; fixing "fingerprint does not match" error
fips=no

[https]
accept=12.34.56.78:443
connect=127.0.0.1:80
TIMEOUTclose=0
xforwardedfor=yes
CAfile = /path/to/ssl/example.com.cabundle
cert=/path/to/ssl/example.com.crt
key=/path/to/ssl/example.com.key

Anyone has any insight as to what's happening here? Googled for multiple hours now, can't figure it out.

OpenSSL version: OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008.

Stunnel version: 4.32

EDIT:

Here is an output of openssl s_client -connect example.com:443 -ssl3

CONNECTED(00000004)
3897:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1086:SSL alert number 40
3897:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:

Same with -tls1 works OK, without any errors.

up vote 9 down vote accepted

Ok, problem was solved... I added this to configuration:

sslVersion = all
options = NO_SSLv2

As far as I understand, error was related to SSLv23. Now all works as expected.

  • I also needed to add fips = no – Steve Tauber Nov 20 '14 at 12:10
  • You can also add option = NO_SSLv3 to force one of the TLS variants to be selected. – Tedford Dec 9 '15 at 22:31

SSL3_GET_RECORD:wrong version number is the key. It seems that lynx on your CentOS systems isn't using SSLv3.

It'll be easier to check the exact behavior with openssl s_client:

Check what happens with just SSLv3:

openssl s_client -connect server:443 -ssl3

And with just TLS:

openssl s_client -connect server:443 -tls1
  • Edited the post to provide more details – Sergey Aug 19 '11 at 17:06
  • Try adding -no_ticket to the SSLv3 attempt. Looks like this OpenSSL bug. – Shane Madden Aug 19 '11 at 17:46
  • Hmm, shows unknown option – Sergey Aug 19 '11 at 19:03
  • @Serge That's.. strange. What do you get from openssl version? – Shane Madden Aug 19 '11 at 19:08

I had to set

options = -NO_SSLv3

to deactivate the now default option of NO_SSLv3. (The server connecting to doesn't do TLS)

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.