[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] SSL handshake fails between libcurl and libgnutls/MH

From: Christian Grothoff
Subject: Re: [libmicrohttpd] SSL handshake fails between libcurl and libgnutls/MHD
Date: Mon, 23 Jan 2012 23:53:04 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111110 Lightning/1.0b1 Icedove/3.0.11

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

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
but even then you have issues like being vulnerable to the "beast"

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]