[libmicrohttpd] SSL handshake fails between libcurl and libgnutls/MHD

[Christian Grothoff]

Ok, so here is what I know now:

1) the bug is not in libmicrohttpd or libgnutls as updating/downgrading 
these libraries does not change the appearance or non-appearance of the bug

2) The more verbose form of the output (VERBOSE in curl) is:

* About to connect() to 127.0.0.1 port 42433 (#0)
* Trying 127.0.0.1... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* gnutls_handshake() failed: No supported cipher suites have been found.
* Closing connection #0
* SSL connect error
curl_easy_perform failed: `SSL connect error'
Error: received handshake message out of context
Error (code: 4294967295)


3) However, the bug is not because I pick specific ciphers; I can 
specify (in GNUtls/OpenSSL-syntax, depending on where) that "all" (or 
"export") ciphers are allowed for server & client; the bug is specific 
to me specifying the use of SSL3 with curl using CURL_SSLVERSION_SSL3, 
with TLS1 the problem does not arise.

4) It is not a bug with the Debian package; compiling 7.23.1 by hand 
produces the same issue as the Debian package.

5) The bug is not present in curl 7.22.0 but DOES occur in 7.23.0 and 
7.23.1.


I've compiled all of those cURL versions using
./configure --with-gnutls=/usr --prefix=/home/grothoff/ --without-ssl


For the time being, I'm still collecting information about the bug in 
our bugtracker at https://gnunet.org/bugs/view.php?id=2086

Happy hacking,

Christian


On 01/19/2012 11:40 PM, Daniel Stenberg wrote:
> On Thu, 19 Jan 2012, Christian Grothoff wrote:
>
>> One of our tests also provokes a failure by selecting incompatible
>> versions of the SSL protocol. With older versions, that test produces
>> ONCE:
>>
>> curl version: libcurl/7.21.3 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.18
>> curl_easy_perform failed: `SSL connect error'
>> Error: received handshake message out of context
>>
>> With the latest version, the two lines are repeated several times (and
>> the test now fails).
>
> Can you try with only changing libcurl OR gnutls to see which change
> that introduces the problem?
>
>> My guess right now is that there must have been some incompatible (!)
>> protocol change in gnutls with itself (!?) or a significant change in
>> how libcurl uses gnutls (i.e. change of supported ciphers, certificate
>> checking, etc.).
>
> I know GnuTLS has changed default crypto backend which probably implies
> some amount of changes. libcurl has not changed the GnuTLS-layer code in
> any significant way in a long time AFAICS. Although I don't think that a
> bug necessarily needs a significant change to occur...
>
> I've not seen or heard anyone else report about similar problems with
> libcurl+gnutls...
>