[libmicrohttpd] SSL handshake fails between libcurl and libgnutls/MHD
Christian Grothoff
christian at grothoff.org
Mon Jan 23 23:53:04 CET 2012
On 01/23/2012 11:14 PM, Daniel Stenberg wrote:
> On Mon, 23 Jan 2012, Nikos Mavrogiannopoulos wrote:
>
>> It doesn't look right. I'd change "-VERS-TLS-ALL:+VERS-SSL3.0" with
>> "NORMAL:-VERS-TLS-ALL:+VERS-SSL3.0".
>>
>> However your priority string seem quite radical. You only allow SSL 3.0.
>
> That particular logic is only running when SSL 3.0 is explicitly asked for.
Hehe. That's what I get for testing rarely used code paths ;-). Note
that this was done in testcases, not in code that I would expect to use
in production ;-).
>> If you care about interoperability I'd suggest a string similar to
>> http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html
>> but even then you have issues like being vulnerable to the "beast"
>> attack.
>
> I'm sorry but I'm not very familiar with SSL at a detailed protocol
> level. Can you please tell me how I can ask GnuTLS to use SSL 3.0
> _without_ being vulnerable to something like the "beast" attack?
Even if you could mitigate such attacks, I'm not sure you should. For
example, suppose disabling a cipher would achieve the trick. However,
you might then disable the only cipher that might work with SSLv3, so
suddenly SSLv3 connections that used to work would stop to work.
If the user needs that kind of fine-grained control over ciphers, he
should set the respective GnuTLS options directly by hand and not just
tell you something like "SSLv3-please". There, "DEFAULTS" is fine. The
fact that SSLv3 is vulnerable is not something libcurl can be expected
to fix IMO. After all, do you really want to modify libcurl each time
someone makes some cryptographic progress on some cipher, causing some
people to change their mind as to which cihpers are secure?
MHD simply leaves the complete choice to the client. Here, your API
doesn't allow this, so the only sane choice you have in my book is
'default'. If the GnuTLS 'default' for SSLv3 is vulnerable, that would
not be libcurl's fault in my book (and in fact, in this case I am also
not advocating that GnuTLS should change anything here either at this
time).
I assume that you're changing your string as per Nikos's suggestion and
I strongly suspect that this will resolve this issue.
Happy hacking!
Christian
More information about the Gnutls-devel
mailing list