RE: Enabling Logging in OpenSSL
>From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar >Sent: Tuesday, 18 September, 2012 00:37 >Hello Dave, >Below is what i see in Server Logs >"Encryption is required to connect to this server but the >client library does not support encryption; the connection >has been closed. Please upgrade your client library. >Error: 17835, Severity: 20, State: 1" >Do you have any pointers? Have you encountered any time before >such errors in forum? I've never seen it, no. The first several google hits for SQL server error 17835 strongly suggest that the error might be that the client "library" (aka driver) isn't *configured* correctly, not that it doesn't actually support encryption. I would try to check that first. If you're using one of the several Microsoft "only and forever solution"s, you'll have to find the correct instructions for it, or someone who knows it. I can't help you there (and no one else has chimed in). If the problem is truly that the client doesn't support it -- and it appears your client would have to be older than about 2005 for that to be the case -- then you need a better client. If MS, I would stick with it and upgrade -- upgrading existing product "in place" is one thing MS usually does pretty well. If you're using some third-party product see if it can be upgraded, and if not change to something else, like MS -- or ask to get the encryption requirement relaxed, although depending on the data on this server that may not be possible in the current world of increasing attacks and liability or penalty for breaches. If for some reason you can't use an MS driver and can't find or use a third-party driver, and are left to implement it yourself, you will have to implement TDS *and* SSL. You can use OpenSSL for the SSL part, but I doubt anyone here can help you for TDS. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Enabling Logging in OpenSSL
Hello Dave, Below is what i see in Server Logs "Encryption is required to connect to this server but the client library does not support encryption; the connection has been closed. Please upgrade your client library. Error: 17835, Severity: 20, State: 1" Do you have any pointers? Have you encountered any time before such errors in forum? -mithun On Tue, Sep 18, 2012 at 12:15 AM, Dave Thompson wrote: > >From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar > >Sent: Friday, 14 September, 2012 20:53 > > >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. > > Yes, you already knew that from s_client -debug . > > If you connect to SQLServer and immediately start an SSL handshake, > the server considers it illegal and closes. So, don't do that. > > If you *are* doing the TDS needed to start SSL but it isn't working > right, there should be some error indication *in TDS* (but I don't > know what) and you shouldn't even attempt the SSL handshake. > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
RE: Enabling Logging in OpenSSL
>From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar >Sent: Friday, 14 September, 2012 20:53 >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. Yes, you already knew that from s_client -debug . If you connect to SQLServer and immediately start an SSL handshake, the server considers it illegal and closes. So, don't do that. If you *are* doing the TDS needed to start SSL but it isn't working right, there should be some error indication *in TDS* (but I don't know what) and you shouldn't even attempt the SSL handshake. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Enabling Logging in OpenSSL
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 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
> wrote:
>
> > 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.
> >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).
>
>
> > In this case, you must implement the TDS protocol, or at least the
> part
> > of it that starts SSL.
> > 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
>
> >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 Listopenssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
RE: Enabling Logging in OpenSSL
>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 wrote: > 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. >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). > In this case, you must implement the TDS protocol, or at least the part > of it that starts SSL. > 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 >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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Enabling Logging in OpenSSL
Thanks Dave, Please find my reply inline. On Tue, Sep 11, 2012 at 8:08 AM, Dave Thompson wrote: > >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 > 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 > > >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. > > 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? JSSE tracing indeed gives in detail log on the handshake , Unfortunately i am not sure how to enable the same on SQLServer !!! > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
RE: Enabling Logging in OpenSSL
>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 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 >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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Enabling Logging in OpenSSL
Hello Dave, Please find my reply inline On Mon, Sep 10, 2012 at 1:52 PM, Dave Thompson wrote: > >From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar > >Sent: Monday, 10 September, 2012 01:56 > > Answering -users only, this isn't a -dev question. > > >I have a challenge befor me where i have to debug a SSL handshake > >failure. Client has OpenSSL libraries and Server is Microsoft > >SQL Server. I cant sniff the packets using WireShark nor can i > >enable server logs. All i can do i enable client logging. Any > >suggestions how to enable OpenSSL logging? > > 1. Are you not permitted to use WireShark, or just having > difficulty doing so? If the latter, maybe we can help. > WireShark's decoding is much easier than doing it by hand. > > Mithun>> Yes i am not allowed to use WireShark. > 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 soniclx24(misingh): openssl s_client -connect NC-WIN2008X64:1433 -state -debug -msg -ssl3 CONNECTED(0003) SSL_connect:before/connect initialization write to 08A018A8 [08A0B660] (100 bytes => 100 (0x64)) - 16 03 00 00 5f 01 00 00-5b 03 00 50 3f fb 58 60 _...[..P?.X` 0010 - 71 d6 9f 3c a6 fb 60 79-8a 31 fe 39 68 46 0e a0 q..<..`y.1.9hF.. 0020 - 3f 0d c8 08 d9 62 da c6-17 fc 8d 00 00 34 00 39 ?b...4.9 0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f .8.5...3.2./ 0040 - 00 66 00 05 00 04 00 63-00 62 00 61 00 15 00 12 .f.c.b.a 0050 - 00 09 00 65 00 64 00 60-00 14 00 11 00 08 00 06 ...e.d.` 0060 - 00 03 01 ... 0064 - >>> SSL 3.0 Handshake [length 005f], ClientHello 01 00 00 5b 03 00 50 3f fb 58 60 71 d6 9f 3c a6 fb 60 79 8a 31 fe 39 68 46 0e a0 3f 0d c8 08 d9 62 da c6 17 fc 8d 00 00 34 00 39 00 38 00 35 00 16 00 13 00 0a 00 33 00 32 00 2f 00 66 00 05 00 04 00 63 00 62 00 61 00 15 00 12 00 09 00 65 00 64 00 60 00 14 00 11 00 08 00 06 00 03 01 00 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 ? > 3. Look at the code for s_client (and s_cb.c) and do in your > app what it does: write a message callback and attach it > to SSL and/or a BIO callback and attach it to the line BIO. > You can probably omit some of the decoding, but > you still need probably 20-50 lines or so. > > >I have enabled API calls "err_error_string_n" and > >"err_peek_error_line_data" to get the error information. Any suggestions? > > By "enabled" you mean you call them after an error occurs? > These routines begin with ERR_ (case matters in C). Many > errors have more than one entry in the error queue; to see > all of them you need to use _get_ not _peek_. > Mithun>> I am using API ERR_peek_error_line_data() > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
RE: Enabling Logging in OpenSSL
>From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar >Sent: Monday, 10 September, 2012 01:56 Answering -users only, this isn't a -dev question. >I have a challenge befor me where i have to debug a SSL handshake >failure. Client has OpenSSL libraries and Server is Microsoft >SQL Server. I cant sniff the packets using WireShark nor can i >enable server logs. All i can do i enable client logging. Any >suggestions how to enable OpenSSL logging? 1. Are you not permitted to use WireShark, or just having difficulty doing so? If the latter, maybe we can help. WireShark's decoding is much easier than doing it by hand. 2. If it's a handshake failure, can you use commandline s_client? That has logging builtin, use -msg and/or -debug . 3. Look at the code for s_client (and s_cb.c) and do in your app what it does: write a message callback and attach it to SSL and/or a BIO callback and attach it to the line BIO. You can probably omit some of the decoding, but you still need probably 20-50 lines or so. >I have enabled API calls "err_error_string_n" and >"err_peek_error_line_data" to get the error information. Any suggestions? By "enabled" you mean you call them after an error occurs? These routines begin with ERR_ (case matters in C). Many errors have more than one entry in the error queue; to see all of them you need to use _get_ not _peek_. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
