Hello Dave,
On the issue i am working currently after i connect to a SQL Server, Client
hello is sent successfully but I am not getting server hello and READ()
below returns as highlighted. Looks like server is closing the connection
after receiving a client hello. On the screen i see Socket Closed
exception.
s3_both.c:401
if (s->state == st1) /* s->init_num < 4 */
{
int skip_message;
do
{
while (s->init_num < 4)
{
i=s->method->ssl_read_bytes(s,SSL3_RT_HANDSHAKE,
&p[s->init_num],4 - s->init_num, 0);
if (i <= 0)
{
s->rwstate=SSL_READING;
*ok = 0;
return i; //returns here
}
s->init_num+=i;
}
Any troubleshooting tips to debug the Issue as SQL Server starts with TDS
and not SSL? I am blocked on this issue. I have already tried s_client and
discussion related to it is in our previous mail chain. How to know if any
firewall or middle box are not playing spoil sport?
Any inputs will be of great help.
-mithun
On Wed, Sep 12, 2012 at 8:25 AM, Dave Thompson <dthomp...@prinpay.com>wrote:
> >From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar
> >Sent: Tuesday, 11 September, 2012 02:10
>
> >On Tue, Sep 11, 2012 at 8:08 AM, Dave Thompson <dthomp...@prinpay.com>
> wrote:
> <snip>
> > 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, SQLSrver will consider this a violation of TDS
> protocol.
> > <snip> 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).
> <snip>
>
> > In this case, you must implement the TDS protocol, or at least the
> part
> > of it that starts SSL. <snip>
> > 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 <snip>
>
> >Mithun>>I am trying to connect to SQLServer which by default starts in
> TDS.
>
> >you said " 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"
>
> >Did you get the events logged in SQLServer Log's? Can you please elaborate
> >so that i can confirm what i am seeing?
>
> I found it in the Windows application eventlog because that's
> quicker for me to use, but it is also in the SQLServer ERRORLOG.
> There was exactly one event for the one ssl3 handshake attempt.
>
> >JSSE tracing indeed gives in detail log on the handshake , Unfortunately
> >i am not sure how to enable the same on SQLServer !!!
>
> I don't know about any SSL or other connection logging in SQLServer.
> But do you need to? If there is no network problem in between,
> the messages sent and received by the client, here jtds, are the
> same as the messages received and sent by the server.
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
