2012/2/7 Daniel Stenberg wrote:

> It is also tempting to use this new option to allow for disabling possibly
> different work-arounds so perhaps a more generic CURLOPT_SSL_WORK_AROUND
> with a bitmask argument would make sense...

Perhaps naming it CURLOPT_SSL_OPTIONS with the bitmask style argument
you mention would be the most flexible. Or even something a bit more
specialized would be having one for vulnerabilities other for chiphers
another one for TLS extensions (CURLOPT_SSL_VULNERABILITIES,
CURLOPT_SSL_CIPHERS, CURLOPT_SSL_TLS_EXT) and so on, each with its own
bitmask.

Whatever way you choose, I would love that simply reading the
curl_easy_setopt() line, or bitmask, makes very clear if a
vulnerability is being introduced or not. If we use the word
'workaround'... are we enabling the workaround for the workaround that
introduces the vulnerability or are we enabling the workaround that
disables it? See what I mean?

BTW MS has already released patches for CVE-2011-3389 for all
supported platforms
(http://technet.microsoft.com/en-us/security/bulletin/ms12-006) And is
also experiencing interoperability issues, this might force
fixing/updating server/proxy software at a higher rate.

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html