secur32: Take schannel backend capabilities into account when configuring enabled protocols.

[Jacek Caban]

Hi Juan,

On 03/28/13 21:55, Juan Lang wrote:
> On Thu, Mar 28, 2013 at 12:31 PM, Ken Thomases <ken at codeweavers.com
> <mailto:ken at codeweavers.com>> wrote:
>
>     On Mar 28, 2013, at 6:05 AM, Jacek Caban wrote:
>
>     > --- a/dlls/secur32/schannel_macosx.c
>     > +++ b/dlls/secur32/schannel_macosx.c
>     > @@ -630,6 +630,11 @@ static OSStatus
>     schan_push_adapter(SSLConnectionRef transport, const void *buff,
>     >      return ret;
>     >  }
>     >
>     > +DWORD schan_imp_enabled_protocols(void)
>     > +{
>     > +    /* NOTE: No support for TLS 1.1 and TLS 1.2 */
>     > +    return SP_PROT_SSL2_CLIENT | SP_PROT_SSL3_CLIENT |
>     SP_PROT_TLS1_0_CLIENT;
>
>
> Do we really want to continue supporting SSL2? It's got a number of
> vulnerabilities, and is disabled pretty much everywhere by now:
> http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_2.0

I implemented it the way it's done in Windows. It's a bit
under-documented and contains usual MSDN mistakes, so let me explain
what I found when testing Windows (most of it is implemented by
http://source.winehq.org/git/wine.git/commitdiff/0f2e0365ea1f5c6baba4cfd9c0ff69defe66d7ea).

Each protocol has two kinds of enable/disable flags: "enabled" and
"disabled by default". Those have different default values for each
protocol and there are registry setting allowing to change each of them.
Only "enabled" protocols are used at all. This patch limits "enabled"
protocols to those that we can really support. If an application asks
schannel to use default set of protocols (which I'd expect them to do
unless they have a good reason), schannel will use all "enabled"
protocols that are not "disabled by default". An alternative to default
set of protocols is listing each allowed separately.

This means that if protocol is "enabled" and "disabled by default" it
won't be used unless application explicitly asks for it. SSL2 is such a
protocol by default. Do you think we should do this differently?

Thanks,
Jacek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20130329/7a52a2fa/attachment.html>