On Sat, 25 Dec 2010, Quinn Slack wrote:

> OK, the configure.ac feature is now "TLS-SRP", the options are
> CURLOPT_TLSAUTH_*, the version is CURL_VERSION_TLSAUTH_SRP, and the error is
> CURLE_TLSAUTH_FAILED. Updated patch pasted below and at:
>
> http://stanford.edu/~sqs/curl-tls-srp-20101224.patch

Lovely! (and I appreciate how small and unintrusive it is!)

> It doesn't work with GnuTLS 1.2, unfortunately. GnuTLS 2.0.1 (2007-09-20)
> changed the SRP cipher suite values to the official IANA-assigned values,
> which completely broke backwards compatibility. It definitely works with
> GnuTLS 2.3 releases (I tried 2.3.5, 2008-04-14, gnutls git 8460e8a3). The
> earliest release it works with is probably 2.2.0 (2007-12-14); I can figure
> out for sure in a week or so. Want me to add a check for a minimum GnuTLS
> version before enabling TLS-SRP in configure.ac?

We need to make sure that the GnuTLS builds either require a new enough
version or fails with a message explaining why, OR we make the SRP support
conditional so that older GnuTLS versions still work for all other SSL stuff
and only SRP doesn't work.

It would be really cool if someone who's actually using GnuTLS in production
or so would speak up on this. What is a decent and sensible lowest version
number to keep supporting?

I think it will make sense to still get some #define set internally in libcurl
when TLSAUTH support is found and used, so that we can make curl_easy_setopt()
return failure for the cases where an app would try to set the TLSAUTH options
without there being underlying support for them.

> I'll also work on some tests (will have to figure out how to get stunnel
> working with TLS-SRP).

Cool! But since stunnel is OpenSSL-based, won't this require that we build
stunnel with an OpenSSL with the SRP patch applied?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html