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
