>From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar
>Sent: Monday, 10 September, 2012 08:17
>On Mon, Sep 10, 2012 at 1:52 PM, Dave Thompson <dthomp...@prinpay.com>
wrote:
> 2. If it's a handshake failure, can you use commandline
> s_client? That has logging builtin, use -msg and/or -debug .
>Mithun>>Last time i used i got the below
>...openssl s_client -connect NC-WIN2008X64:1433 -state -debug -msg -ssl3
<snip>
>SSL_connect:SSLv3 write client hello A
>read from 08A018A8 [08A06E50] (5 bytes => 0 (0x0))
>SSL_connect:failed in SSLv3 read server hello A
>12542:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:529:
>I see your reply
> Read count 0 nominally means the server closed the TCP connection,
> neither continuing the handshake (with ServerHello)nor cleanly aborting
> (with alert). A compliant server shouldn't do this, but some do,
especially
> if it judges you shouldn't be allowed to connect e.g. blacklisted IPaddr,
> too many attempts too fast, etc. Ask the server operator(s) why it
> didn't/doesn't like you.
> Alternatively, there is a remote possibility some middlebox in your
> network path such as a firewall is doing the close. However middleboxes
> usually do this earlier: on the TCP connection (SYN) not during SSL
> handshake, which is "just" data to the TCP/IP level.
>Any work around that you suggest ?
I didn't notice before, but 1433 on Windows is usually SQLServer.
If so, SQLServer doesn't start in SSL; it starts in a SQLServer protocol
(TDS) and optionally switches to SSL. If you connect to 1433 and just start
an SSL handshake, SQLServer will consider this a violation of TDS protocol.
This falls under the case in my prior reply "make sure the server is doing
SSL". And in fact on my elderly SQLServer2005 Express, connecting to 1433
and starting -ssl3 handshake does exactly as you report, with an event
logged:
source=MSSQLSERVER eventid=17836
Length specified in network packet payload did not match number of bytes
read;
the connection has been closed. Please contact the vendor of the client
library.
[CLIENT: 127.0.0.1]
whereas a (default) ssl2 clienthello hangs (at least 1minute).
Looking briefly at a trace of a clear TDS connection, it appears that
bytes 2 and 3 are (bigendian inclusive) length, and in ssl3 clienthello
these are 00 00 which is clearly invalid, whereas in ssl2 clienthello
they are 01 00 which is longer than the message actually sent, thus
the server is likely waiting for the rest of the supposed TDS message.
In this case, you must implement the TDS protocol, or at least the part
of it that starts SSL. (And once you get SSL, you still need to implement
the TDS protocol if you want to use the connection for anything.)
I haven't found protocol doc or sourcecode available from Microsoft
(which doesn't prove it isn't there somewhere I don't know about).
freetds.sourceforge.net claims to be an opensource driver
implementation, using either gnutls or openssl; I haven't tried it,
but it might work for you, or looking at the source might help.
jtds.sourceforge.net is a Java port of freetds that I do use okay,
and Java's SSL implementation (JSSE) has the feature that (fairly
verbose) logging can be turned on by a sysprop without code change:
http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefG
uide.html#Debug
If 1433 is not SQLServer, I'm back to: find out what it dislikes.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
