http://bugs.winehq.org/show_bug.cgi?id=30598
Bug #: 30598 Summary: Evernote can't connect to server Product: Wine Version: 1.5.3 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wininet AssignedTo: wine-bugs@winehq.org ReportedBy: isloginov@gmail.com Classification: Unclassified
Evernote running under latest wine from repository can't connect to server. wine reports following:
fixme:wininet:INET_QueryOption INTERNET_OPTION_CONNECTED_STATE: semi-stub fixme:wininet:InternetAttemptConnect Stub fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (60000): STUB fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT/DATA_SEND_TIMEOUT 60000 fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT/DATA_SEND_TIMEOUT 300000 err:wininet:NETCON_secure_connect SSL_connect failed: 12157
Last message was generated in dlls/wininet/netconnection.c:
if (pSSL_connect(ssl_s) <= 0) { res = (DWORD_PTR)pSSL_get_ex_data(ssl_s, error_idx); if (!res) res = ERROR_INTERNET_SECURITY_CHANNEL_ERROR; ERR("SSL_connect failed: %d\n", res); goto fail; }
Looking man SSL_connect I've read that SSL_get_error should be used. It returns SSL_ERROE_SYSCALL.
man tells following:
SSL_ERROR_SYSCALL
Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error (for socket I/O on Unix systems, consult errno for details).
It is not clear to me what to do next. ERR_get_error() returns 0 and errno == 0 too.
http://bugs.winehq.org/show_bug.cgi?id=30598
Ilya Loginov isloginov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isloginov@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #1 from Ilya Loginov isloginov@gmail.com 2012-05-05 02:27:14 CDT --- Created attachment 40038 --> http://bugs.winehq.org/attachment.cgi?id=40038 Fix Evernote authefication problem with latest wine
http://bugs.winehq.org/show_bug.cgi?id=30598
Ilya Loginov isloginov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #2 from Ilya Loginov isloginov@gmail.com 2012-05-05 02:35:45 CDT --- I've founded some post in the Evernote's blog: http://blog.evernote.com/tech/2011/09/23/security-hang-ups/
I can't get robots.txt from www.evernote.com with curl as described above. So I tried:
openssl s_client -ssl3 -state -debug -msg -connect www.evernote.com:443
All was fine.
I removed ssl3 key and got it! It failed to connect. So I tried to enable SSLv3_client_method in wine and problem was gone.
Of course, it's bad patch because, probably, it breaks many other applications. There should be somewhere switch on some parameter to chose method but I can't find any proper method to set authefication method on MSDN to make proper fix.
http://bugs.winehq.org/show_bug.cgi?id=30598
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |adys.wh@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30598
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #3 from Bruno Jesus 00cpxxx@gmail.com 2012-05-05 13:57:04 CDT --- Please attach a +winttp log. If the program is freely available please fill the URL field and add the "download" keyword.
My guess is that WinHttpSetOption is being called with WINHTTP_OPTION_SECURE_PROTOCOLS option but it is not supported yet. As far as I can see this call is used to change the protocol used [1].
If I'm correct this line should be in the log with option 84 [2]. session.c:186 - FIXME("unimplemented option %u\n", option);
Or maybe I'm completely wrong and the method should be extracted somehow from the handshake message =)
[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa384066%28v=vs.85%2... [2] http://source.winehq.org/source/include/winhttp.h#L116
http://bugs.winehq.org/show_bug.cgi?id=30598
Ilya Loginov isloginov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://evernote.com/intl/ru | |/download/
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #4 from Ilya Loginov isloginov@gmail.com 2012-05-05 16:21:45 CDT --- Created attachment 40048 --> http://bugs.winehq.org/attachment.cgi?id=40048 WINEDEBUG=+winhttp
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #5 from Ilya Loginov isloginov@gmail.com 2012-05-05 16:22:32 CDT --- Created attachment 40049 --> http://bugs.winehq.org/attachment.cgi?id=40049 WINEDEBUG=+secur32,+crypt,+winsock,+wininet
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #6 from Ilya Loginov isloginov@gmail.com 2012-05-05 16:27:07 CDT --- It looks like Evernote does not use winhttp at all.
But looking into wininet log I've founded something interesting:
trace:wininet:InternetSetOptionW (0x3 31 0x2fce058 4)
MSDN says that 31 is INTERNET_OPTION_SECURITY_FLAGS [1]. Indeed it says also that
SECURITY_FLAG_SSL3 0x00000004 Not implemented.
But I will look into it and try to find out if Evernote pass this flag to InternetSetOption.
[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa385328(v=vs.85).as...
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #7 from Ilya Loginov isloginov@gmail.com 2012-05-05 17:15:59 CDT --- It passes 0x2081 as value of INTERNET_OPTION_SECURITY_FLAGS flag:
SECURITY_FLAG_SECURE | SECURITY_FLAG_IGNORE_REVOCATION | SECURITY_FLAG_IGNORE_CERT_DATE_INVALID
Nothing that points to SSL3. But there noted on the page http://msdn.microsoft.com/en-us/library/windows/desktop/aa384066(v=vs.85).as... that
By default only SSL3 and TLS1 are enabled.
May it be a problem?
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #8 from Bruno Jesus 00cpxxx@gmail.com 2012-05-05 19:25:41 CDT --- (In reply to comment #7)
... May it be a problem?
I don't know, let's wait for Jacek or anyone more experienced to check this. My only guess was about that option being ignored but as it's not set I don't know what else could it be.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #9 from Ilya Loginov isloginov@gmail.com 2012-05-06 02:45:57 CDT --- I sure that problem is in OpenSSL changes:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/965371
Also I found this thread:
http://www.mentby.com/Group/openssl-users/sslv23method-in-openssl-100.html
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #10 from Bruno Jesus 00cpxxx@gmail.com 2012-05-06 08:59:41 CDT --- Have you tried with the previous openssl version (I think it's 0.98)? If you test and it works with it the bug is definately not in wine and this report should be marked resolved->upstream.
http://bugs.winehq.org/show_bug.cgi?id=30598
david.h.vree@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david.h.vree@gmail.com
--- Comment #11 from david.h.vree@gmail.com 2012-05-08 08:20:41 CDT --- It *may* be an upstream OpenSSL problem, but this does work in Wine 1.4 without issue. Something in Wine 1.5.3 has cause the issue to surface.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #12 from Ilya Loginov isloginov@gmail.com 2012-05-08 11:58:33 CDT --- Actually, it is not true. I've just checked wine 1.4 (built from sources). The issue is present there.
I try to understand is there bug in OpenSSL or it is some kind of evolutionary changes. Did you read Steven's post in openssl-users (I gave link) about changes in default behavior if SSLv23_method?
If so potentionally there is bug in wine and it should be fixed.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #13 from david.h.vree@gmail.com 2012-05-08 13:10:55 CDT --- I should be more specific. When I run Wine 1.4 from the Ubuntu repos, I also cannot connect. But when I run "Wine 1.4" from my installation of PlayOnLinux (on the same machine) it DOES work.
I do not have any idea why POL's 1.4 works and Ubuntu (and yours) doesn't. Can you try POL with a 1.4 instance of Wine and see if it works for you?
http://bugs.winehq.org/show_bug.cgi?id=30598
Denys Golubiev denys.golubiev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |denys.golubiev@gmail.com
--- Comment #14 from Denys Golubiev denys.golubiev@gmail.com 2012-05-09 04:45:19 CDT --- (In reply to comment #13)
Can you try POL with a 1.4 instance of Wine and see if it works for you?
I can confirm that POL's version 1.4 works fine with Evernote. Checked on ubuntu 12.04. Neither ubuntu repository nor winehq ppa version 1.4 doesn't work.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #15 from Ilya Loginov isloginov@gmail.com 2012-05-09 13:08:09 CDT --- There is no surprising that Play on Linux's version of wine 1.4 works.
PoL disribute wine as precompiled with openssl 0.9.8 tarball:
$ tar -tf PlayOnLinux-wine-1.4-linux-x86.pol | grep ssl wineversion/1.4/lib/libssl.so wineversion/1.4/lib/libssl.so.0.9.8
P.S. I had thought that PoL's wine is statically linked.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #16 from david.h.vree@gmail.com 2012-05-10 10:52:54 CDT --- Well that pretty much cliches it that this is an upstream problem, no?
Zero progress on the Ubuntu OpenSSL bug... :-(
http://bugs.winehq.org/show_bug.cgi?id=30598
Rob rob@rboone.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rob@rboone.com
http://bugs.winehq.org/show_bug.cgi?id=30598
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan.lang@gmail.com, | |nerv@dawncrow.de
--- Comment #17 from André H. nerv@dawncrow.de 2012-06-12 12:43:00 CDT --- maybe an upstream bug, but maybe we can do something about it in wine if the upstream change has good reasons.
Adding Juan Lang
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #18 from Juan Lang juan.lang@gmail.com 2012-06-13 12:40:22 CDT --- 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 ;)
In the longer term, we'd need some tests of the protocol-level behavior of wininet. I have started to write such tests for secur32, but never got very far with them. If you can demonstrate with wireshark what the problem is, and that SSLv23_method fixes the protocol-level behavior, that might be sufficient justification, without going as far as writing your own protocol parser for the regression tests.
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.
http://bugs.winehq.org/show_bug.cgi?id=30598
web@robsonfamily.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |web@robsonfamily.co.uk
--- Comment #19 from web@robsonfamily.co.uk 2012-06-16 04:44:48 CDT --- This is also affecting Newsbin, it cannot register itself, or connect to any ssl servers. (64 bit version) I have tried 1.4,1.53, pol 1.4 & 1.53 all with the same problem.
This is the error from Newsbin [10:20:48] ERROR InterSocket - Error: SSL Negotiation Failed, Host: news.giganews.com Error: SSL Connection Failed: 5 Error 0 Success.
and from the NB support pages.( http://forums.newsbin.com/viewtopic.php?f=31&t=30453&p=185475)
#define SSL_ERROR_SYSCALL 5 /* look at error stack/return value/errno */
This is error 5. It's saying something in Wine's socket layer's dropping the ball.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #20 from Juan Lang juan.lang@gmail.com 2012-06-16 08:44:49 CDT --- (In reply to comment #19)
This is also affecting Newsbin, it cannot register itself, or connect to any ssl servers. (64 bit version)
Please don't confuse bugs, this merits its own bug. Please open one.
http://bugs.winehq.org/show_bug.cgi?id=30598
web@robsonfamily.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|web@robsonfamily.co.uk |
http://bugs.winehq.org/show_bug.cgi?id=30598
Richard C rac9876@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rac9876@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30598
Owyn i.leacy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |i.leacy@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #21 from Hiroshi Miura miurahr@linux.com 2012-08-20 10:36:25 CDT --- Created attachment 41438 --> http://bugs.winehq.org/attachment.cgi?id=41438 A patch to fix wininet and winhttp to behave same as Windows
This is caused by OpenSSL 1.0.x now support TLSv1.1 and TLSv1.2 by default but Windows7 is disabled by Default. and IIS server is also disabled by default.
When connecting from client claiming TLSv1.1 or TLSv1.2, Evernote server returns protocol version failure.
This patch add functionality to enable/disable TLSv1.1 and TLSv1.2 based on registry entry.
(refers: http://netsekure.org/2009/10/tls-1-2-in-windiows-7/ )
For future, wininet.dll and winhttp.dll should implement using secur32 schannel. The registry where a patch refers is for schannel.
I'm tested on Ubuntu 12.04(64bit) multi-arch and Evernote 4.5.2.4504.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #22 from André H. nerv@dawncrow.de 2012-08-20 12:23:12 CDT --- (In reply to comment #21)
Created attachment 41438 [details] A patch to fix wininet and winhttp to behave same as Windows
That patch looks really great at first view, you should split it up into a winhttp and a wininet patch and send it to wine-patches@winehq.org to recieve more feedback. Also patches are not picked up from bugzilla.
For some input you can also have a look at: http://wiki.winehq.org/SubmittingPatches
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
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #24 from Hiroshi Miura miurahr@linux.com 2012-08-25 21:58:16 CDT --- Created attachment 41483 --> http://bugs.winehq.org/attachment.cgi?id=41483 Registry entry disables TLS1.1/1.2 support.
This is registry file to add a entry to disable tls v1.1/1.2 support.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #25 from Hiroshi Miura miurahr@linux.com 2012-08-25 21:59:00 CDT --- Created attachment 41484 --> http://bugs.winehq.org/attachment.cgi?id=41484 Registry entry enables TLS1.1/1.2 support.
This is a registry file to add a entry to enable tls v1.1/1.2 support.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #26 from Hiroshi Miura miurahr@linux.com 2012-08-25 22:03:24 CDT --- (In reply to comment #21)
Created attachment 41438 [details] A patch to fix wininet and winhttp to behave same as Windows
This has a bug when tls1.1/1.2 registry entry exist. I'll post new patch to wine-patches@winehq.org
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #27 from Hiroshi Miura miurahr@linux.com 2012-08-25 22:04:26 CDT --- Created attachment 41485 --> http://bugs.winehq.org/attachment.cgi?id=41485 A test win32 program to reproduce and check behavior of wininet.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #28 from Hiroshi Miura miurahr@linux.com 2012-08-25 22:05:03 CDT --- Created attachment 41486 --> http://bugs.winehq.org/attachment.cgi?id=41486 test program binary
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #29 from Bruno Jesus 00cpxxx@gmail.com 2012-08-31 22:50:18 CDT --- (In reply to comment #28)
Created attachment 41486 [details] test program binary
What is this program supposed to do? It seems to download several packets for me in wine 1.5.12 and then it dumps a html page.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #30 from Hiroshi Miura miurahr@linux.com 2012-09-01 01:34:51 CDT --- This program(In reply to comment #29)
(In reply to comment #28)
Created attachment 41486 [details] test program binary
What is this program supposed to do? It seems to download several packets for me in wine 1.5.12 and then it dumps a html page.
This program connect https://www.evernote.com and get html using wininet dll. When your WINE/OpenSSL is affected this bug, you see error message of program and wine.
If you use Wine with openssl 1.0.1 and later, you will see like
$ wine wine_wininet_tls_test.exe > test.html err:wininet:NETCON_secure_connect SSL_connect failed: 12157
With my patch, $ wine wine_wininet_tls_test.exe > test.html may successfully get html from evernote.com
edit registry to support TLS1.1/1.2 $ wine regedit import tls12_enable.reg
You will see same result with unpatched version. $ wine wine_wininet_tls_test.exe > test.html err:wininet:NETCON_secure_connect SSL_connect failed: 12157
and then disable TLS1.1/1.2 with registry by regedit importing tls12_disable.reg you will see successfully get html.
If you use OpenSSL 1.0.0h and before such as 0.9.8m, which is not support TLS1.1/1.2, you always success to get html from evernote.com using test program.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #31 from Bruno Jesus 00cpxxx@gmail.com 2012-09-01 04:43:52 CDT --- (In reply to comment #30)
... If you use OpenSSL 1.0.0h and before such as 0.9.8m, which is not support TLS1.1/1.2, you always success to get html from evernote.com using test program.
Thanks, that's why it always works for me.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #32 from david.h.vree@gmail.com 2012-09-18 15:32:06 CDT --- Has this patch been applied?
I am still seeing this error on Wine 1.5.13 on Ubuntu 12.04 with Evernote installer 4.5.8.7356.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #33 from Hiroshi Miura miurahr@linux.com 2012-09-22 21:14:45 CDT ---
(In reply to comment #32)
Has this patch been applied?
I am still seeing this error on Wine 1.5.13 on Ubuntu 12.04 with Evernote installer 4.5.8.7356.
http://source.winehq.org/patches/ http://source.winehq.org/patches/data/89343
My proposed patch is still waiting for processing.
http://bugs.winehq.org/show_bug.cgi?id=30598
Marcus Meissner marcus@jet.franken.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus@jet.franken.de
http://bugs.winehq.org/show_bug.cgi?id=30598
JR zorael@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zorael@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #34 from david.h.vree@gmail.com 2012-10-15 16:50:47 CDT --- I see the patch has been processed. I assume that the future release of Wine 1.5.16 should have the fix in it...yes?
1.5.15 does not have the fix it as far as I can tell.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #35 from Bruno Jesus 00cpxxx@gmail.com 2012-10-15 18:24:46 CDT --- (In reply to comment #34)
I see the patch has been processed. I assume that the future release of Wine 1.5.16 should have the fix in it...yes?
I can't find the commit in git. As far as I remember this was the last message about it and I could not find newer versions of the patch: http://wine.1045685.n5.nabble.com/Re-wininet-disable-TLSv1-1-1-2-by-default-...
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #36 from André H. nerv@dawncrow.de 2012-10-16 13:41:21 CDT --- (In reply to comment #34)
I see the patch has been processed. I assume that the future release of Wine 1.5.16 should have the fix in it...yes?
What does tell you the patch has been processed?
dlls/wininet/netconnection.c wasn't changed since June
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #37 from Juan Lang juan.lang@gmail.com 2012-10-16 13:50:56 CDT --- (In reply to comment #36)
(In reply to comment #34)
I see the patch has been processed. I assume that the future release of Wine 1.5.16 should have the fix in it...yes?
What does tell you the patch has been processed?
I suspect it was a simple misunderstanding of the patches list: the patch disappeared off the end of the list.
David: AFAIR the patch wasn't reviewed. This is the dreaded "not obviously correct" patch status, in which Alexandre isn't convinced, but he's not quite sure what's wrong with the patch, either. It's up to the patch author to reflect what might be done to improve it. As I recommended in comment 18, tests that demonstrate that Windows really does behave this way by default would be pretty convincing. They're also not easy.
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #38 from Hiroshi Miura miurahr@linux.com 2012-10-27 09:20:36 CDT ---
I posted new version of patch. It implement fall back mechanism which is similar as what Wininet in Windows7 does.
http://osdir.com/ml/wine-patches/2012-10/msg00965.html
http://bugs.winehq.org/show_bug.cgi?id=30598
--- Comment #39 from Hiroshi Miura miurahr@linux.com 2012-10-27 21:49:28 CDT --- Evernote problem is likely a server problem because openssl and gnutls also fails to connect with command line utility.
$ openssl s_client -connect www.evernote.com:443 $ gnutls-cli www.evernote.com
both fails to negotiate ssl.
I found result of ' gnutls-cli-debug www.evernote.com' show that
Checking for TLS 1.0 support... yes Checking for TLS 1.1 support... no Checking fallback from TLS 1.1 to... failed Checking for TLS 1.2 support... no
'$ gnutls-cli-debug sandbox.evernote.com' shows
Checking for TLS 1.0 support... yes Checking for TLS 1.1 support... no Checking fallback from TLS 1.1 to... SSL 3.0 Checking for TLS 1.2 support... no
and sandbox works fine.
But Evernote client for windows works fine on MS windows7. Because 1. WIndows 7 don't enable TLS1.1/1.2 by default 2. Windows 7 have a mechanism to fall back(close socket and create new connection) to SSLv3/TLSv1 that is not defined in IETF RFC.
My first proposal is implement (1) but fails to accept. So I take an approach (2).
http://bugs.winehq.org/show_bug.cgi?id=30598
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |923ac2e546e5f86afd319d944a0 | |a249bc1fa1e4a Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #40 from André H. nerv@dawncrow.de 2012-11-01 16:29:55 CDT --- committed: http://source.winehq.org/git/wine.git/commitdiff/923ac2e546e5f86afd319d944a0...
http://bugs.winehq.org/show_bug.cgi?id=30598
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #41 from Alexandre Julliard julliard@winehq.org 2012-11-09 13:00:52 CST --- Closing bugs fixed in 1.5.17.