Evernote client can not connect evernote.com server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Wine |
Fix Released
|
Medium
|
|||
wine1.4 (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
on Ubnut 12.04, Evernote cannot connect evernote.com server, because OpenSSL 1.0.1 version support TLS1.1/1.2 and evernote server does not, and Wine does not treat it well.
http://
Here is a patch that fix this by disabling TLS1.1/1.2 by default and help user to enable TLS1.1/1.2 with configuration.
I report it upstream but it still in review.
Users who use Ubuntu and Evernote affect it and unusable Evernote client from April when 12.04 release.
In Wine Bugzilla #30598, Ilya Loginov (isloginov) wrote : | #4 |
Created attachment 40038
Fix Evernote authefication problem with latest wine
In Wine Bugzilla #30598, Ilya Loginov (isloginov) wrote : | #5 |
I've founded some post in the Evernote's blog: http://
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.
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.
In Wine Bugzilla #30598, Bruno Gonçalves de Jesus (00cpxxx) wrote : | #6 |
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_
If I'm correct this line should be in the log with option 84 [2].
session.c:186 - FIXME("
Or maybe I'm completely wrong and the method should be extracted somehow from the handshake message =)
[1] http://
[2] http://
In Wine Bugzilla #30598, Ilya Loginov (isloginov) wrote : | #7 |
Created attachment 40048
WINEDEBUG=+winhttp
In Wine Bugzilla #30598, Ilya Loginov (isloginov) wrote : | #8 |
Created attachment 40049
WINEDEBUG=
In Wine Bugzilla #30598, Ilya Loginov (isloginov) wrote : | #9 |
It looks like Evernote does not use winhttp at all.
But looking into wininet log I've founded something interesting:
trace:wininet:
MSDN says that 31 is INTERNET_
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://
In Wine Bugzilla #30598, Ilya Loginov (isloginov) wrote : | #10 |
It passes 0x2081 as value of INTERNET_
SECURITY_
Nothing that points to SSL3. But there noted on the page http://
By default only SSL3 and TLS1 are enabled.
May it be a problem?
In Wine Bugzilla #30598, Bruno Gonçalves de Jesus (00cpxxx) wrote : | #11 |
(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.
In Wine Bugzilla #30598, Ilya Loginov (isloginov) wrote : | #12 |
I sure that problem is in OpenSSL changes:
https:/
Also I found this thread:
http://
In Wine Bugzilla #30598, Bruno Gonçalves de Jesus (00cpxxx) wrote : | #13 |
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.
In Wine Bugzilla #30598, Dave Vree (hdave) wrote : | #14 |
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.
In Wine Bugzilla #30598, Ilya Loginov (isloginov) wrote : | #15 |
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.
In Wine Bugzilla #30598, Dave Vree (hdave) wrote : | #16 |
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?
In Wine Bugzilla #30598, Golden (denys-golubiev) wrote : | #17 |
(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.
In Wine Bugzilla #30598, Ilya Loginov (isloginov) wrote : | #18 |
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-
wineversion/
wineversion/
P.S. I had thought that PoL's wine is statically linked.
In Wine Bugzilla #30598, Dave Vree (hdave) wrote : | #19 |
Well that pretty much cliches it that this is an upstream problem, no?
Zero progress on the Ubuntu OpenSSL bug... :-(
In Wine Bugzilla #30598, Andre_H (nerv-dawncrow) wrote : | #20 |
maybe an upstream bug, but maybe we can do something about it in wine if the upstream change has good reasons.
Adding Juan Lang
In Wine Bugzilla #30598, Juan-lang-s (juan-lang-s) wrote : | #21 |
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.
In Wine Bugzilla #30598, Bx09m7-web-zwnfzp (bx09m7-web-zwnfzp) wrote : | #22 |
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://
#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.
In Wine Bugzilla #30598, Juan-lang-s (juan-lang-s) wrote : | #23 |
(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.
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #24 |
Created attachment 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://
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.
In Wine Bugzilla #30598, Andre_H (nerv-dawncrow) wrote : | #25 |
(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 <email address hidden> to recieve more feedback.
Also patches are not picked up from bugzilla.
For some input you can also have a look at:
http://
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #26 |
(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://
*2 http://
*3 http://
*4 http://
*5
http://
*6 http://
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #27 |
Created attachment 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.
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #28 |
Created attachment 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.
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #29 |
(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 <email address hidden>
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #30 |
Created attachment 41485
A test win32 program to reproduce and check behavior of wininet.
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #31 |
Created attachment 41486
test program binary
In Wine Bugzilla #30598, Bruno Gonçalves de Jesus (00cpxxx) wrote : | #32 |
(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.
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #33 |
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:/
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_
err:wininet:
With my patch,
$ wine wine_wininet_
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_
err:wininet:
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.
In Wine Bugzilla #30598, Bruno Gonçalves de Jesus (00cpxxx) wrote : | #34 |
(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.
In Wine Bugzilla #30598, Dave Vree (hdave) wrote : | #35 |
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.
Logan Rosen (logan) wrote : | #1 |
Bug 965371 appears to be related, and it suggests a potential OpenSSL fix rather than a Wine one.
affects: | wine (Ubuntu) → wine1.4 (Ubuntu) |
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #36 |
(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://
http://
My proposed patch is still waiting for processing.
Hiroshi Miura (miurahr) wrote : | #2 |
- ssldump debug output Edit (1.9 KiB, text/plain)
I've also been wandaring that Bug 965371 affected.
Problem is on TLS version that client requests evernote server.
Client ask server to request TLS1.2 version( in pakcet , 3.3), and server respond version error alert.
Pls see ssl dump log. it was got with Evernote client running on Wine1.4.1.
(wine1.
same result can be got with wine 1.4, too.
server returns TCP FIN immediately after request.
The evernote server is not support 'secure renegotiation'.
When using patched wine, client request TLS1.0 and works fine.
openssl is 1.0.1-4ubuntu5.5
Changed in wine: | |
importance: | Unknown → Medium |
status: | Unknown → New |
In Wine Bugzilla #30598, Dave Vree (hdave) wrote : | #37 |
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.
In Wine Bugzilla #30598, Bruno Gonçalves de Jesus (00cpxxx) wrote : | #38 |
(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://
In Wine Bugzilla #30598, Andre_H (nerv-dawncrow) wrote : | #39 |
(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/
In Wine Bugzilla #30598, Juan-lang-s (juan-lang-s) wrote : | #40 |
(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.
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #41 |
I posted new version of patch.
It implement fall back mechanism which is similar as what Wininet in Windows7 does.
In Wine Bugzilla #30598, Hiroshi Miura (miurahr) wrote : | #42 |
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.
$ 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.
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).
Launchpad Janitor (janitor) wrote : | #43 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in wine1.4 (Ubuntu): | |
status: | New → Confirmed |
Changed in wine: | |
status: | New → Fix Released |
In Wine Bugzilla #30598, Alexandre Julliard (julliard) wrote : | #45 |
Closing bugs fixed in 1.5.17.
Evernote running under latest wine from repository can't connect to server. wine reports following:
fixme:wininet: INET_QueryOptio n INTERNET_ OPTION_ CONNECTED_ STATE: semi-stub InternetAttempt Connect Stub InternetSetOpti onW Option INTERNET_ OPTION_ CONNECT_ TIMEOUT (60000): STUB InternetSetOpti onW INTERNET_ OPTION_ SEND/RECEIVE_ TIMEOUT/ DATA_SEND_ TIMEOUT 60000 InternetSetOpti onW INTERNET_ OPTION_ SEND/RECEIVE_ TIMEOUT/ DATA_SEND_ TIMEOUT 300000 NETCON_ secure_ connect SSL_connect failed: 12157
fixme:wininet:
fixme:wininet:
fixme:wininet:
fixme:wininet:
err:wininet:
Last message was generated in dlls/wininet/ netconnection. c:
if (pSSL_connect( ssl_s) <= 0) PTR)pSSL_ get_ex_ data(ssl_ s, error_idx); SECURITY_ CHANNEL_ ERROR;
ERR("SSL_ connect failed: %d\n", res);
{
res = (DWORD_
if (!res)
res = ERROR_INTERNET_
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.