[stunnel-users] Problem with sslv2 clients

Fri Dec 9 15:37:33 CET 2011

Hi,

we have a strange problem with newer stunnel versions (4.50 on windows), 
compared to older ones (known to work is version 4.35). The problem 
seems to be, that if a client sends a SSLv2 Helo message, the stunnel 
server simply resets the TCP connection, without trying to negotioate 
anything.

Setup: Stunnel is used top provide ssl/tls for imap, Hobbit is used to 
monitor service availability. The Hobbit module to monitor imaps seems 
to try SSLv2 first, but also supports newer versions (SSLv3 and TLSv1). 
The ssl connection never gets established, stunnel sends a tcp RST, 
hobbit never retries. We can force some hobbit modules to use TLSv1 
exclusively, but not all of them. We fear that some older mailclients 
will also have problems initiating a connection, so we keep stunnel 4.35 
running for now.

stunnel.conf:

fips = no
debug = 7
output = stunnel.log

[imaps]
accept  = 130.83.174.1:993
connect = 127.0.0.1:143
cert    = imap.xxx.company.yy.pem

stunnel.log:

2011.12.09 14:55:12 LOG5[6820:2144]: Service imaps accepted connection from xxx.yyy.zzz.105:45294
2011.12.09 14:55:12 LOG3[6820:2144]: SSL_accept: 1408F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
2011.12.09 14:55:12 LOG5[6820:2144]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2011.12.09 14:55:12 LOG7[6820:2144]: Service imaps finished (0 left)
2011.12.09 14:55:12 LOG7[6820:2144]: str_stats: 0 block(s), 0 data byte(s), 0 control byte(s)

Wireshark Packet Trace (see attached image).

What's wrong here? Shouldn't client and server negotiate the methods 
used? The client seems to offer TLS ("Version: TLS 1.0 ..."), but 
instead of negotiating, the server simply closes the connection.

Greetings
Markus Borst

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stunnel_sslv2_RST.png
Type: image/png
Size: 30666 bytes
Desc: not available
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20111209/7c1dea9d/attachment.png>