Evernote client can not connect evernote.com server

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.

Created attachment 40038
Fix Evernote authefication problem with latest wine

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.

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%29.aspx
[2] http://source.winehq.org/source/include/winhttp.h#L116

Created attachment 40048
WINEDEBUG=+winhttp

Created attachment 40049
WINEDEBUG=+secur32,+crypt,+winsock,+wininet

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).aspx

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).aspx that

By default only SSL3 and TLS1 are enabled.

May it be a problem?

(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.

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

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.

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.

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.

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 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.

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.

Well that pretty much cliches it that this is an upstream problem, no?

Zero progress on the Ubuntu OpenSSL bug... :-(

maybe an upstream bug, but maybe we can do something about it in wine if the upstream change has good reasons.

Adding Juan Lang

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.

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.

(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.

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://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.

(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://wiki.winehq.org/SubmittingPatches

(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.html
*6 http://code.google.com/p/chromium/issues/detail?id=142172

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.

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 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>

Created attachment 41485
A test win32 program to reproduce and check behavior of wininet.

Created attachment 41486
test program binary

(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(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.

(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.

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.

(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.

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 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-td5725632.html

(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

(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.

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

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).

committed:
http://source.winehq.org/git/wine.git/commitdiff/923ac2e546e5f86afd319d944a0a249bc1fa1e4a

Closing bugs fixed in 1.5.17.