[stunnel-users] Problem with sslv2 clients

[Markus Borst]

Thanks for the tipp, I have already tried to re-enable SSLv2, which does 
indeed "work".

But, to repeat myself: I do _NOT_ want to _USE_ SSLv2.

I want client and server to _NEGOTIATE_ a "higher" protocol.

In laymens terms, this is how I _think_ it should work:

Client: Hi there dear server. I'd like to initiate a SSLv2 connetion. 
But, if you run with one of those newfangled installations which support 
TLSv1, that's fine by me too. (See open packet in the packet trace in my 
first e-mail.)

Server: Sure, I wouldn't dream of accepting a SSLv2 connection, but 
TLSv1 is fine.


What seems to happen instead is this:

Client: (as above)

Server: You are not worthy of an answer. Go away!



Of course, I'm not an expert in SSL protocols, so please correct me if I 
misunderstood the actual protocol negotiation.


Greetings
Markus Borst





-------- Original Message  --------
Subject: Re: [stunnel-users] Problem with sslv2 clients
From: Ludovic LEVET <llevet at ludosoft.org>
To: stunnel-users at stunnel.org
Date: Sun Dec 11 2011 15:03:23 GMT+0100
> Try this conf :
>
> stunnel.conf:
>
> fips = no
> sslVersion = all
> ciphers = ALL
>
>
> [imaps]
> accept  = 130.83.174.1:993
> connect = 127.0.0.1:143
> protocol = imap
> cert    = imap.xxx.company.yy.pem
>
>
> Ludo.
>
>
> Le 10/12/2011 14:26, Markus Borst a écrit :
>> Sorry, my mistake for not being clearer: I do not want to use SSLv2,
>> I want the automatic negotiation to work. The client does not get any
>> kind of response from stunnel, instead, the TCP connection is closed!
>> (RST packet)
>>
>> I'm no expert for ssl, but it looks to me, like the client tried
>> SSLv2 first, but offered TLSv1 also (please see screenshot of packet
>> trace in my first mail). The server did not answer with it's
>> capabilities, but simply closed the connection.
>>
>> Is this really normal? Shouldn't stunnel answer, in protocol, that it
>> only supports certain other encryption methods?
>>
>> Greetings
>> Markus Borst
>>
>>
>> Am 09.12.2011 19:14, schrieb Ludovic LEVET:
>>> Hi,
>>>
>>> Normal, SSLv2 is disable by default since version 4.40.
>>> (http://www.stunnel.org/?page=sdf_ChangeLog)
>>> To re-enable it add in your config file :
>>>
>>> ciphers = ALL:!aNULL:!EXP:!LOW:-MEDIUM:RC4:+HIGH  (or other)
>>> and
>>> sslVersion = all
>>>
>>>
>>> Ludovic.
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> Le 09/12/2011 15:37, Markus Borst a écrit :
>>>>> 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
>>>>>
>>>>
>
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> http://stunnel.mirt.net/mailman/listinfo/stunnel-users


-- 

TU Darmstadt
Hochschulrechenzentrum (HRZ)
Markus Borst
S4/14/2.4.06
Adresse: 	Mornewegstr. 30   64293 Darmstadt
Tel.: 	06151/16-2056
Email: 	M.Borst at hrz.tu-darmstadt.de