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@ludosoft.org To: stunnel-users@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@stunnel.org http://stunnel.mirt.net/mailman/listinfo/stunnel-users

Am 12.12.2011 16:57, schrieb Michal Trojnara:

Markus Borst wrote:

...

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

fips = no sslVersion = all options = NO_SSLv2

According to my tests it does exactly what you want.

Mike

Sorry for the late reply. Yes, thanks, this combination does indeed work. Older ssl client can connect and use either sslv3 or tlsv1. I would have thought that this would be default behaviour, but there are probably reasons to do it otherwise.

Since the use of these options in this combination is not clear from the documentation, I have a few suggestions to update the docs: - explain what fips does (not the whole specification, just which methods and ciphers are disabled) - clearly state which methods (SSL, TLS, ciphers) are used by default, with or without fips. - explain the "options = NO_SSLv2" option. Currently, it is not even mentioned. As a longer term enhancement, I suggest making the "sslVersion" option multi-valued: Currently, I can only select one of the three, or all three, but not just two out of three. (I.e., what will we do when a TLSv2 comes around?)

And the above configuration should go as an example into the default config file, since this particular combination ("sslVersion=all" AND "options=NO_SSLv2") ist a bit counter intuitive.

Greetings Markus Borst