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

[Christian Grothoff]

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