http://bugs.winehq.org/show_bug.cgi?id=30598
Hiroshi Miura miurahr@linux.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |miurahr@linux.com
--- Comment #23 from Hiroshi Miura miurahr@linux.com 2012-08-20 19:51:03 CDT --- (In reply to comment #18)
I don't think an easy fix will be forthcoming, at least not from me. The SSLv23_method approach may well work, and it might even get accepted. One of you ought try that, at least ;)
There may be a discussion about a behaviour of WinINET TLSv1.1 renegotiation. It seems different with OpenSSL's SSLv23_method. It is also questioned for interoperability by IETF specialist(*1).
That's because I don't want to change Wine's wininet behavior as same as windows. It only disables TLS 1.1/1.2 by default and provide a way to enable it thru registry configuration(*4).
When discussing only about Evernote, enabling TLS1.2 on Evernote.com server's IIS/Windows is a solution(*5). Chrome Browser also deal with IIS TLS 1.1/1.2 issue by similar way.(*6)
Another stated goal for some years has been to move away from reliance on OpenSSL: wininet should really use secur32/schannel for its SSL/TLS needs, so at least we'd only have to fix protocol-level errors in one place. Still, that's not necessarily going to fix this bug: it would just move the reliance on OpenSSL into a reliance on GnuTLS, which might well have the same behavior.
I agree it. My patch(*2) is for interim solution and we should go forward to use secur32/schannel and GnuTLS for wininet and winhttp. There is also a dilemma on license compatibility; among LGPL, original-BSD, and GPL(*3)
*1 http://www.ietf.org/mail-archive/web/tls/current/msg08070.html *2 http://bugs.winehq.org/attachment.cgi?id=41438 *3 http://curl.haxx.se/legal/distro-dilemma.html *4 http://netsekure.org/2009/10/tls-1-2-in-windiows-7/ *5 http://www.adminhorror.com/2011/10/enable-tls-11-and-tls-12-on-windows_1853.... *6 http://code.google.com/p/chromium/issues/detail?id=142172