Hi,

I'm trying to fix a bug in gwibber, which is having trouble connecting to
Twitter's API server using python-curl, which uses libcurl-gnutls.

The symptom is that I get "SSL connection timeout at ..." errors, as in the
following:

Twitter : DEBUG Setting up monitors
Twitter : DEBUG Refresh interval is set to 15
Twitter : DEBUG ** Starting Refresh - 2011-05-18 06:34:59.90 **
Twitter : DEBUG <twitter:receive> Performing operation
Twitter : DEBUG <twitter:responses> Performing operation
* About to connect() to api.twitter.com port 443 (#0)
* Trying 199.59.148.88... * About to connect() to api.twitter.com port 443
(#0)
* Trying 199.59.148.87... * connected
* Connected to api.twitter.com (199.59.148.88) port 443 (#0)
* found 142 certificates in /etc/ssl/certs/ca-certificates.crt
* connected
* Connected to api.twitter.com (199.59.148.87) port 443 (#0)
* found 142 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL connection timeout at 147237
* Closing connection #0

It seems that someone else reported this bug a few weeks ago and it was
determined that recompiling libcurl against OpenSSL made the problem go
away.

http://curl.haxx.se/mail/lib-2011-04/0242.html
http://curl.haxx.se/mail/lib-2011-05/0015.html

I've done a little more digging and I found that:

1. Although I'm using an old version of gnutls (2.8.6), this is not a
problem with gnutls -- gnutls-cli performs the handshake successfully,
whereas libcurl does not.

2. When running a hand-built curl on an HTTPS URL, I see the same error:

ethan_at_jonah-hex:~/software/curl-7.21.3$ ./debian/build-gnutls/src/curl
https://github.com
curl: (28) SSL connection timeout at 297679

3. This error is new; I did not see it in Ubuntu 10.10 (but I see it now
that I have upgraded to 11.04).

4. It seems that the relevant change is a change to gtls.c:handshake, here:

https://github.com/bagder/curl/commit/cbf4961bf3e42d88f6489f981efd509faa86f501#L0L219

Previously, performing a handshake would block until the timeout ran out.
With this change, it times out after a second, and if the SSL handshake
hasn't finished by then, it errors out with an SSL timeout message. Like
the original bug reporter, I am on a high-latency CDMA network, and it is
very rare that the SSL handshake is finished in under a second.

This change was purportedly made because of a problem where timeouts were
shadowing some other problem:

https://github.com/bagder/curl/commit/cbf4961bf3e42d88f6489f981efd509faa86f501#L0L219

I wanted to ask what the original intent of this change was -- it looks like
perhaps if the 1-second timeout happens, the for(;;) loop should continue
and poll for another second? Or is it expected that all handshakes should
finish in a second, and if it doesn't, there's another problem?

For now I'm increasing the timeout to ten seconds, but I'm curious what the
"correct" solution is.

Thanks for your time.

Ethan

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-05-18