cURL / Mailing Lists / curl-library / Single Mail


Bug: libcurl-GnuTLS SSL handshake timeouts

From: Ethan <>
Date: Wed, 18 May 2011 12:34:08 -0400


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

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 port 443 (#0)
* Trying * About to connect() to port 443
* Trying * connected
* Connected to ( port 443 (#0)
* found 142 certificates in /etc/ssl/certs/ca-certificates.crt
* connected
* Connected to ( 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

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
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:

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:

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.


List admin:
Received on 2011-05-18