ssl connection issues

[Michael Blumenkrantz]

On Wed, 29 Sep 2010 17:35:14 -0400
Michael Blumenkrantz <mike at zentific.com> wrote:

> On Wed, 29 Sep 2010 15:06:27 -0400
> Michael Blumenkrantz <mike at zentific.com> wrote:
> 
> > On Wed, 29 Sep 2010 17:17:56 +0200
> > Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > 
> > > On 09/29/2010 04:48 PM, Michael Blumenkrantz wrote:
> > > 
> > > > If that were the case, wouldn't it also fail when I have paused
> > > > execution as I described previously?  Additionally, the only function
> > > > that is sending data on that socket during that time is
> > > > gnutls_handshake.
> > > 
> > > I can only speculate as I cannot reproduce the issue. If you think you
> > > know how to reproduce it, check mini-egain example, and see whether you
> > > can emulate the behavior you're seeing there.
> > > 
> > > To the point. As I see the problem is not on receiving. This happens
> > > normally as I see from your log. Check with wireshark and other ways
> > > that the send is occuring as it should.
> > > 
> > > regards,
> > > Nikos
> > Hmm I have spent some time working on a very tiny async app using gnutls.
> > It utilizes a single callback to handshake and then disconnect from a
> > server, as I will describe later.  In my testing with this, however, I
> > uncovered a larger and previously unknown bug in pre-existing software
> > which I have now begun the long task of attempting to fix.  Thank you for
> > your advice.
> > 
> > In thanks, I have written and documented a small test program (attached)
> > which performs an asynchronous remote connection to verisign.com (an easy
> > site to find that has an ssl certificate).  It requires eina and ecore from
> > the EFL/enlightenment.org to compile/run, but should serve as a good
> > standalone reading example to include since it is well-commented and short
> > (11 gnutls calls, 3 ecore calls total).  Feel free to modify/redistribute
> > if you would like, with or without attribution.  I hope you find it useful.
> > 
> As it turns out, in an amusing accident I sent you a "mostly finished" version
> of the file which is not async.  Attached is the actual async example.
> 
As it turns out, I have fixed the bug which I found from this but it did not
fix my gnutls problem (though it has made it easier to read the logs).  I have
uploaded the logs to avoid having a giant email message.  They can be found
here:

functioning log from example I sent to mailing list: http://www.zentific.com/files/example.log
nonfunctioning log from internal code: http://www.zentific.com/files/ecore.log

This is the internal code relevant to gnutls in the exact order that it is called:

gnutls_certificate_allocate_credentials(&svr->cert);
gnutls_anon_allocate_client_credentials(&svr->anoncred_c);
gnutls_init(&svr->session, GNUTLS_CLIENT);
gnutls_session_ticket_enable_client(svr->session);
gnutls_server_name_set(svr->session, GNUTLS_NAME_DNS, svr->name, strlen(svr->name));
gnutls_priority_set_direct(svr->session, "NONE:%VERIFY_ALLOW_X509_V1_CA_CRT:+RSA:+DHE-RSA:+DHE-DSS:+ANON-DH:+COMP-DEFLATE:+COMP-NULL:+CTYPE-X509:+SHA1:+SHA256:+SHA384:+SHA512:+AES-256-CBC:+AES-128-CBC:+3DES-CBC:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+VERS-SSL3.0", NULL);
gnutls_credentials_set(svr->session, GNUTLS_CRD_CERTIFICATE, svr->cert);
gnutls_credentials_set(svr->session, GNUTLS_CRD_ANON, svr->anoncred_c);
gnutls_dh_set_prime_bits(svr->session, 512;
gnutls_transport_set_ptr(svr->session, (gnutls_transport_ptr_t)svr->fd);

/* this is called in an event handler from select() on svr->fd */
gnutls_handshake(svr->session);


As far as I can tell, the gnutls code is the same. Wireshark reports that all the bytes supposedly sent have been sent as far as I am able to tell, though I have also uploaded wireshark logs (in wireshark reading format) for each connection attempt:

http://www.zentific.com/files/ecore_wireshark.log
http://www.zentific.com/files/example_wireshark.log

The underlying code for the version that does not work is identical as well; the socket gets the event from select() and immediately calls gnutls_handshake() again just as in the example.  As mentioned before, any type of slowdown during the execution of the ecore (nonfunctioning) code will allow it to succeed somehow, so this must be a timing issue somewhere.  Additionally, I have tested disabling O_NONBLOCK with the ecore (nonfunctioning) code and verified that it does connect correctly then.

I am out of ideas here, so I have attempted to provide as much info as possible so that perhaps someone will see something that I have missed, or at least point me in the direction to provide more information.  I am currently in the process of setting up a local apache test server to debug from the server side and attempt to pinpoint the error since it is the only course of action that I can think of.

Please help! :)
-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.