-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
HTTPS fails when running curl/libcurl using wine #983
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
That's an interesting setup. Not to discourage you but I am curious why not just run curl directly? Unfortunately I don't have a lot of insight here. There was a change that was made to support ALPN and in 7.50 if Windows < 8.1 it should not be used. That you can't connect even with ALPN disabled (I'm assuming here) means it's something else, but I don't know what. Can you take a wireshark capture of the working 7.48 and the failing 7.50 and give us the Also, it looks like GnuTLS is actually what is used to connect? Wine maps the schannel calls to GnuTLS? Try GnuTLS on its own and see what happens. |
I just reviewed the schannel changes in the last few versions (gitk lib/vtls/schannel.c) and I don't see what it could be. I do notice that if ALPN is disabled an empty buffer is passed as InitializeSecurityContext param Try changing &input_desc to NULL in schannel.c, see if that makes a difference. diff --git a/lib/vtls/schannel.c b/lib/vtls/schannel.c
index f991ec9..2b826dc 100644
--- a/lib/vtls/schannel.c
+++ b/lib/vtls/schannel.c
@@ -332,7 +332,7 @@ schannel_connect_step1(struct connectdata *conn, int sockindex)
sspi_status = s_pSecFn->InitializeSecurityContext(
&connssl->cred->cred_handle, NULL, host_name,
- connssl->req_flags, 0, 0, &inbuf_desc, 0, &connssl->ctxt->ctxt_handle,
+ connssl->req_flags, 0, 0, NULL, 0, &connssl->ctxt->ctxt_handle,
&outbuf_desc, &connssl->ret_flags, &connssl->ctxt->time_stamp);
Curl_unicodefree(host_name); |
@jay you may be right about that. From the schannel documentation:
Obviously this isn't 100% correct, given that the ALPN buffer is meant to be passed in here, but perhaps this documentation hasn't been updated post-ALPN implementation. Furthermore, ALPN is working correctly on native Windows, so maybe wine is doing something funny. Anyway, if your suggestion above works, we could do something of this sort:
with the appropriate determination of a |
Thanks, it works with that change! I'm using libcurl in a plugin for an application that does not have a linux version yet, hence wine. curl -V:
wireshark captures of 7.48, vanilla 7.50.1 and modified 7.50.1: http://files.cfillion.tk/curl-983/ |
Thanks for that information guys. The 7.48 and 7.50.1 modified ClientHello are identical except for the random bytes. Christian I think you should report this to Wine as a bug and see what they have to say. Also, I'd be interested whether anyone else reading this is able to reproduce using their own Wine. Please try the fix in this branch. |
I was able to reproduce the problem and can confirm that your commit fixes this specific problem. I am now getting some other errors:
Looks like there are actually two errors here: one in the The first one could be some bad configuration on my part, but the second one looks ominous for wine usage... |
The fix is also working well here. Wine bug report: https://bugs.winehq.org/show_bug.cgi?id=41218 |
- Disable ALPN on Wine. - Don't pass input secbuffer when ALPN is disabled. When ALPN support was added a change was made to pass an input secbuffer to initialize the context. When ALPN is enabled the buffer contains the ALPN information, and when it's disabled the buffer is empty. In either case this input buffer caused problems with Wine and connections would not complete. Bug: #983 Reported-by: Christian Fillion
The workaround landed in 895168b. @JDepooter I am able to reproduce those other problems in Ubuntu 16 LTS with packaged wine-1.6.2 but I don't have a solution. What version of Wine are you using? I think it's possible it was a bug fixed in a later version since Christian has success in 1.9.x |
@jay I was also using 1.6.2. Don't use wine much myself but its good to hear this works in later versions. |
Regarding @slackner Do the flags have any real bearing in that case in Wine? I did a git grep in wine-1.6.2 and I don't see the flag names are really used except tests but I don't know if maybe they are referred to in hex or something somewhere. |
As this is only happening under Wine, isn't this more a Wine bug rather than a curl bug? |
Yes, the remaining issue is a Wine bug that was fixed. I was curious if we could make a simple workaround for it so libcurl w/schannel would work properly on earlier Wine versions. I had pinged Sebastian Lackner who works on the project. If anyone else on Ubuntu LTS is affected in Wine by |
I did this
Curl was built on Windows 10 with Visual Studio 2015 using
I expected the following
Successful download with curl.exe and programs using libcurl.
curl/libcurl version
schannel: failed to retrieve ALPN result
schannel: initial InitializeSecurityContext failed: SEC_E_INVALID_TOKEN
after setting winecfg's Windows Version to < Windows 8 as per "schannel: failed to retrieve ALPN result" when running on Windows 7 #840, otherwise same as 7.49operating system
Curl was ran with wine v1.9.17 on ArchLinux.
The text was updated successfully, but these errors were encountered: