http://bugs.winehq.org/show_bug.cgi?id=16831
Summary: NETCON_secure_connect SSL_connect failed Product: Wine Version: 1.1.12 Platform: PC-x86-64 URL: http://www.audible.com/adbl/site/softwareWizard/Software Windows.jsp?BV_UseBVCookie=Yes OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wininet AssignedTo: wine-bugs@winehq.org ReportedBy: support@tjworld.net
Audible's Manager.exe (version 5.5.0.0) fails to 'Activate' a device (part of the Digital Restrictions Management for the audio books) using SSL (requires an Audible account). This may be related to bug #15482.
The relevant trace fragment (+wininet,+secur32,+schannel) shows:
trace:wininet:HTTP_OpenConnection --> trace:wininet:GetAddress L"www.audible.com"trace:wininet:HTTP_ResolveName resolved L"www.audible.com" to 88.221.113.139 err:wininet:NETCON_secure_connect SSL_connect failed: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol warn:wininet:HTTP_OpenConnection Couldn't connect securely to host trace:wininet:HTTP_OpenConnection 0 <--
Wireshark doesn't show *any* SSL/TLS attempts (on port 443).
Extracting the URL AudibleManager is attempting to open (a GET that includes username and encrypted password) from the trace and pasting it into Firefox, a successful response is returned (and Wireshark shows a complete TLS v1 session).
I'm aiming to test the patch attached to bug #15482, "negotiate TLSv1 instead of SSL2/3" against this.
http://bugs.winehq.org/show_bug.cgi?id=16831
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #1 from Hans Leidekker hans@meelstraat.net 2009-01-06 14:37:28 ---
I'm aiming to test the patch attached to bug #15482, "negotiate TLSv1 instead of SSL2/3" against this.
Good idea. And please attach a full WINEDEBUG=+wininet trace to this bug.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #2 from TJ support@tjworld.net 2009-01-06 14:42:41 --- I didn't attach a complete log since it reveals, in several places, personal account details. Also, apart from the extract quoted, there's nothing else specific to the SSL/TLS connection attempt.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #3 from Austin English austinenglish@gmail.com 2009-01-06 14:53:01 --- (In reply to comment #2)
I didn't attach a complete log since it reveals, in several places, personal account details. Also, apart from the extract quoted, there's nothing else specific to the SSL/TLS connection attempt.
You could edit those parts of the trace out.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #4 from TJ support@tjworld.net 2009-01-06 15:56:22 --- Created an attachment (id=18539) --> (http://bugs.winehq.org/attachment.cgi?id=18539) Trace (with personal details removed)
I've removed all the personal details from the trace log.
http://bugs.winehq.org/show_bug.cgi?id=16831
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18539|application/octet-stream |text/plain mime type| | Attachment #18539|wine-debug.log |wine-debug.txt filename| |
--- Comment #5 from Austin English austinenglish@gmail.com 2009-01-06 16:09:43 --- (From update of attachment 18539) Please use .txt extension.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #6 from TJ support@tjworld.net 2009-01-06 22:56:23 --- The patch from bug #15482 doesn't solve the issue, it just changes the specific error message reported to:
err:wininet:NETCON_secure_connect SSL_connect failed: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
wine --version wine-1.1.12-201-gede9fa8
git-log --pretty=format:"%h %ci %s" ede9fa8 2009-01-07 03:39:23 +0000 Update package version 149ac24 2009-01-06 23:32:27 +0000 Test for bug #16831 NETCON_secure_connect SSL_connect failed d9d7b45 2009-01-06 23:25:11 +0000 Debian packaging 83fc733 2009-01-06 15:11:47 +0100 winedump: Implement dumping of relocations.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #7 from Hans Leidekker hans@meelstraat.net 2009-01-07 04:35:08 --- Created an attachment (id=18556) --> (http://bugs.winehq.org/attachment.cgi?id=18556) wininet: Secure flag has precedence over scheme.
trace:wininet:InternetOpenUrlW (0x1, L"http://www.audible.com/..., (null), 00000000, 80800002, 00000000) trace:wininet:InternetOpenUrlW flags : INTERNET_FLAG_RELOAD INTERNET_FLAG_SECURE INTERNET_FLAG_TRANSFER_BINARY...
This call is ambiguous; the app requests a URL with scheme http (not https) and specifies INTERNET_FLAG_SECURE at the same time. My guess is that native resolves this as a secure request on port 443.
Can you try this patch?
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #8 from TJ support@tjworld.net 2009-01-07 09:13:04 --- I've done some SSL/TLS tests against the server using openssl and cannot reproduce the same fault by forcing protocol versions. It looks possible that something in the set-up of the secure connection parameters is causing this. I shall try the patch and continue investigating.
All of these are successful:
openssl s_client -connect www.audible.com:443 Protocol : TLSv1 Cipher : AES256-SHA openssl s_client -connect www.audible.com:443 -ssl2 Protocol : SSLv2 Cipher : DES-CBC3-MD5 openssl s_client -connect www.audible.com:443 -ssl3 Protocol : SSLv3 Cipher : AES256-SHA openssl s_client -connect www.audible.com:443 -tls1 Protocol : TLSv1 Cipher : AES256-SHA
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #9 from TJ support@tjworld.net 2009-01-07 13:21:23 --- It looks as if the suggested patch contained W.I.P. for setupapi, which I removed.
When tested the trace shows:
err:wininet:NETCON_secure_connect SSL_connect failed: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
I've been reading the source-code and there's some things that don't seem quite right, but as I'm still getting the feel for it you may know better.
It looks as if the patch won't take effect because in INTERNET_InternetOpenUrlW(), the result of
if (urlComponents.nPort == 0)
will be false since the previous call to InternetCrackUrlW() initially sets nPort to 0:
lpUC->nPort = INTERNET_INVALID_PORT_NUMBER
but later assigns the default port to nPort based on the Scheme when no port is specified in the URI:
if (lpszPort != lpszNetLoc) lpUC->nPort = atoiW(++lpszPort); else switch (lpUC->nScheme) { case INTERNET_SCHEME_HTTP: lpUC->nPort = INTERNET_DEFAULT_HTTP_PORT; break; case INTERNET_SCHEME_HTTPS: lpUC->nPort = INTERNET_DEFAULT_HTTPS_PORT; break;
This suggests that the patch logic, and the code it replaced, was unreachable since nPort was always being set by InternetCrackUrlW().
An obvious solution for this bug would be to remove the HTTP/HTTPS default assignments in InternetCrackUrlW() but it looks likely that the function is relied on by many other callers.
I've been considering various alternatives. The key problem is how, in INTERNET_InternetOpenUrlW(), to detect when InternetCrackUrlW() has applied the default values:
1. Set a flag in InternetCrackUrlW() when the defaults are used, that is checked upon return. The problem with this would be where that flag would live. There isn't any obvious spare capacity in URL_COMPONENTS that wouldn't affect other callers.
2. Locate the returned UrlComponents.lpszHostName in the original lpszUrl and check if it is followed by a port specifier ( :[:digit:]{1,5} ). If not, apply the SSL nPort over-ride if the INTERNET_FLAG_SECURE flag is set and the scheme is INTERNET_SCHEME_HTTP.
3. Detect the scheme in lpszUrl and manually over-ride UrlComponents.nScheme after calling InternetCrackUrlW() if the INTERNET_FLAG_SECURE flag is set, then detect whether a port-specifier exists in lpszUrl and if not adjust UrlComponents.nPort.
4. Massage the original lpszUrl (make a copy) *before* the call to InternetCrackUrlW() to alter the scheme string to "https" (if it isn't already) when the INTERNET_FLAG_SECURE is set.
Personally, I prefer option 4 since it is least invasive and simplest to code.
http://bugs.winehq.org/show_bug.cgi?id=16831
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18556|0 |1 is obsolete| |
--- Comment #10 from Hans Leidekker hans@meelstraat.net 2009-01-07 13:59:09 --- Created an attachment (id=18561) --> (http://bugs.winehq.org/attachment.cgi?id=18561) wininet: Secure flag has precedence over scheme.
Please try this patch instead.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #11 from TJ support@tjworld.net 2009-01-07 14:41:19 --- The patch suggested has an obvious logic problem - although it will handle this bug's scenario it won't be able to deal with
"https://host.domain:80/path/to/file?querystring=1#4"
It would cause nPort to be changed from 80 to 443 when the port had explicitly been specified.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #12 from Hans Leidekker hans@meelstraat.net 2009-01-07 14:59:35 ---
The patch suggested has an obvious logic problem - although it will handle this bug's scenario it won't be able to deal with
"https://host.domain:80/path/to/file?querystring=1#4"
It would cause nPort to be changed from 80 to 443 when the port had explicitly been specified.
I'm not proposing it as the final solution, just as a debugging patch. We'll need test cases to find out what happens with other permutations of scheme, port and secure flag.
http://bugs.winehq.org/show_bug.cgi?id=16831
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, patch
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #13 from TJ support@tjworld.net 2009-01-07 15:33:53 --- Okay, that makes more sense :)
I'm building a patch based on option 4 in my earlier analysis that 'simply' inserts an "s" onto the protocol if INTERNET_FLAG_SECURE and lpszUrl begins "http:".
After that I'll test your patch too.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #14 from TJ support@tjworld.net 2009-01-07 16:03:39 --- Created an attachment (id=18563) --> (http://bugs.winehq.org/attachment.cgi?id=18563) Force HTTPS when INTERNET_FLAG_SECURE
This is the patch that represents option 4, tested and working. The following trace extract shows the patch reporting itself and the resulting URL passed to InternetCrackUrlW():
trace:wininet:INTERNET_InternetOpenUrlW (0x26be3d8, L"http://www.audible.com/cgi-bin/licensemgr.cgi?"..., (null), 00000000, 80800002, 00000000) trace:wininet:INTERNET_InternetOpenUrlW adjusting protocol to HTTPS since INTERNET_FLAG_SECURE && "http:" trace:wininet:InternetCrackUrlW (L"https://www.audible.com/cgi-bin/licensemgr.cgi?action="...) ... trace:wininet:NETCON_init using SSL connection
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #15 from TJ support@tjworld.net 2009-01-07 16:44:39 --- Created an attachment (id=18564) --> (http://bugs.winehq.org/attachment.cgi?id=18564) Force HTTPS when INTERNET_FLAG_SECURE - v2
This is a much better implementation of option 4. It relies upon the assertion that INTERNET_FLAG_SECURE and INTERNET_SCHEME_HTTP are mutually exclusive.
A small addition to InternetCrackUrlW() and a change to the calling statement in INTERNET_InternetOpenUrlW() to ensure the dwFlags are passed to it.
This is tested and works correctly. Here's a trace fragment:
trace:wininet:InternetCrackUrlW (L"http://www.audible.com/cgi-bin/licensemgr.cgi?"... 350 80800002 0x32c638) ... trace:wininet:GetInternetSchemeW L"http" 4 trace:wininet:InternetCrackUrlW adjusting protocol to HTTPS since INTERNET_FLAG_SECURE && "http:" trace:wininet:SetUrlComponentValueW L"https" (5) ... trace:wininet:NETCON_init using SSL connection
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #16 from TJ support@tjworld.net 2009-01-07 17:07:29 --- Success using patch 186561 "wininet: Secure flag has precedence over scheme."
Trace fragment shows:
trace:wininet:HTTP_Connect --> trace:wininet:WININET_AddRef 0x26fa1f8 -> refcount = 3 trace:wininet:WININET_AddRef 0x2424240 -> refcount = 2 trace:wininet:WININET_Release object 0x2424240 refcount = 1 trace:wininet:HTTP_Connect 0x26fa1f8 --> 0x2 (0x2424240) trace:wininet:HttpOpenRequestW (0x2, (null), L"/cgi-bin/licensemgr.cgi?action="..., (null), (null), 0x32c674, 80800002, 00000000) trace:wininet:HttpOpenRequestW accept type: L"*/*" trace:wininet:WININET_AddRef 0x2424240 -> refcount = 2 trace:wininet:WININET_GetObject handle 2 -> 0x2424240 trace:wininet:HTTP_HttpOpenRequestW --> trace:wininet:WININET_AddRef 0x2424240 -> refcount = 3 trace:wininet:WININET_AddRef 0x29aa4d0 -> refcount = 2 trace:wininet:NETCON_init using SSL connection
The problem I see with it is that because the URL_COMPONENTSW structure urlComponents.lpszScheme isn't in sync with urlComponents.nScheme or lpszUrl, subsequent code that might be dependent on the strings may behave unexpectedly. It would be most likely where a new URLCOMPONENTSW is built based on the original lpszUrl. This in addition to the "https://host.domain:80/" scenario.
http://bugs.winehq.org/show_bug.cgi?id=16831
TJ support@tjworld.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18563|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #17 from Hans Leidekker hans@meelstraat.net 2009-01-08 03:07:20 ---
A small addition to InternetCrackUrlW() and a change to the calling statement in INTERNET_InternetOpenUrlW() to ensure the dwFlags are passed to it.
InternetCrackUrlW is an API defined by Microsoft, you can't change it like that.
http://bugs.winehq.org/show_bug.cgi?id=16831
TJ support@tjworld.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18564|0 |1 is obsolete| |
--- Comment #18 from TJ support@tjworld.net 2009-01-08 04:10:43 --- Created an attachment (id=18575) --> (http://bugs.winehq.org/attachment.cgi?id=18575) Force HTTPS when INTERNET_FLAG_SECURE - v3
OK, how about a variation since it makes most sense in minimising the code confusion and repetition?
Move the code from InternetCrackUrlW() to a new INTERNET_InternetCrackUrlW() that takes a 'bFix' flag and the connection flags, and that conditionally does the fix-up when bFix == TRUE.
Call the new function from the WINAPI InternetCrackUrlW() with bFix = FALSE to maintain existing functionality and parameter usage.
In INTERNET_InternetOpenUrlW() call INTERNET_InternetCrackUrlW() with bFix = TRUE and the connection flags to use the fix-up.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #19 from Hans Leidekker hans@meelstraat.net 2009-01-08 04:26:01 ---
Move the code from InternetCrackUrlW() to a new INTERNET_InternetCrackUrlW() that takes a 'bFix' flag and the connection flags, and that conditionally does the fix-up when bFix == TRUE.
I find that too hackish. Have you tested what happens with a URL that has an explicit port on Windows?
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #20 from TJ support@tjworld.net 2009-01-08 16:31:59 ---
Have you tested what happens with a URL that has an explicit port on Windows?
Yes. With my patch wine behaves identically (to Windows XP SP2). In other words, Windows behaviour appears to be to 'promote' a protocol to HTTPS when no port is specified and INTERNET_FLAG_SECURE is set. Without the patch wine behaves differently to Windows.
I wrote a program that tests 12 permutations and logs the results. Because there's a lot of formatted output I've put it on my Wiki and summarised it in a table, as well as including the test code and logs.
http://tjworld.net/wiki/Linux/Wine/Bug16831
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #21 from Hans Leidekker hans@meelstraat.net 2009-01-09 01:10:52 ---
I wrote a program that tests 12 permutations and logs the results.
Good work. It would be even better if you could add these to Wine's test suite (dlls/wininet/tests/http.c) and mark the tests that fail as todo_wine.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #22 from TJ support@tjworld.net 2009-01-09 04:23:57 ---
Good work. It would be even better if you could add these to Wine's test suite (dlls/wininet/tests/http.c) and mark the tests that fail as todo_wine.
Thank you. I did consider adding them to the test suite but for the issue that the tests are doing live connections and I thought it possible that the tests may run on systems that have no Internet connectivity.
A second issue is that the test results are based on the live connection test, *not* the state of the URL_COMPONENTS structure - which is the key issue in this bug. From what I could see of the WINAPI there is no way to examine the internal state of that structure or control the request at a lower level that would allow an application to examine it.
Also, this only tests one path to a connection and from what I see there are several other ways the WinAPI might proceed.
Obviously some tests are meant to fail so they'd be considered a success :)
I'm willing to do some more work on integrating tests based on the current work if these issues can be resolved or put aside.
Going back to the patch - with these results is the patch now more acceptable?
I've looked in detail for better ways to achieve the end result but so far they would all require a large body of essentially duplicate code in the caller to InternetCrackUrlW() to check the prerequisites for forcing the change.
The only other solution, albeit requiring a whole bunch of duplicate pre-requisite code, is to provide a separate fix-up function that can be called by internal functions.
There are other callers, some of which might require the same fix-up, which suggests the 'static' storage-class should be dropped. Some are outside the module too - would it need exporting in some way?
dlls/urlmon/http.c:344: in HttpProtocol_Start() dlls/urlmon/umon.c:550: in URLMonikerImpl_BindToStorage_hack() dlls/urlmon/umon.c:730: in URLMonikerImpl_BindToStorage()
The wiki suggests HTTPS 'shares most code' with HTTP, so these probably need dealing with too. (http://wiki.winehq.org/UrlMon)
dlls/wininet/cookie.c:198: in COOKIE_crackUrlSimple() dlls/wininet/internet.c:1277: in InternetCrackUrlA() dlls/wininet/internet.c:2734: in InternetCheckConnectionW() dlls/wininet/internet.c:2848: in INTERNET_InternetOpenUrlW() dlls/wininet/http.c:1332: in HTTP_DealWithProxy() dlls/wininet/http.c:2980: in HTTP_HandleRedirect()
dlls/cryptnet/cryptnet_main.c:478: in CRYPT_CrackUrl() dlls/cryptnet/cryptnet_main.c:914: in File_RetrieveEncodedObjectW() dlls/cryptnet/cryptnet_main.c:996: in CRYPT_GetRetrieveFunction()
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #23 from Hans Leidekker hans@meelstraat.net 2009-01-09 04:33:29 ---
Thank you. I did consider adding them to the test suite but for the issue that the tests are doing live connections and I thought it possible that the tests may run on systems that have no Internet connectivity.
If you look at dlls/wininet/tests/http.c you'll see that we already have tests that do live connections. They fail gracefully if a connection can't be made. You'll want to replace www.audible.com with test.winehq.org or codeweavers.com (which has https enabled), so we don't burden audible.com.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #24 from TJ support@tjworld.net 2009-01-09 08:53:44 --- Created an attachment (id=18595) --> (http://bugs.winehq.org/attachment.cgi?id=18595) Add secure connections tests to test suite
You'll want to replace www.audible.com with test.winehq.org or codeweavers.com (which has https enabled), so we don't burden audible.com.
I've added the tests to the test suite. I *think* I've used the correct mechanisms (based on studying other tests) but I'd welcome review of the attached patch. I basically ported my stand-alone tests. Have I understood the use of "todo_wine" correctly?
Alas, testing against codeweavers HTTPS server actually causes a test to succeed that is expected to fail:
http.c:2209: Test failed: test_secure_url (http:// www.codeweavers.com :443 (null) ) failed, expected error 12152, got error 0
The reason is, the codeweavers HTTPS server has been configured to handle HTTP requests nicely! Is there an alternative host to target which ignores HTTP on HTTPS ?
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #25 from Hans Leidekker hans@meelstraat.net 2009-01-09 09:23:38 ---
I've added the tests to the test suite. I *think* I've used the correct mechanisms (based on studying other tests) but I'd welcome review of the attached patch. I basically ported my stand-alone tests. Have I understood the use of "todo_wine" correctly?
Looks good, though you should use HeapAlloc rather than LocalAlloc.
Alas, testing against codeweavers HTTPS server actually causes a test to succeed that is expected to fail:
Hmm, does wiki.winehq.org work better?
http://bugs.winehq.org/show_bug.cgi?id=16831
TJ support@tjworld.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18595|0 |1 is obsolete| |
--- Comment #26 from TJ support@tjworld.net 2009-01-09 09:53:47 --- Created an attachment (id=18596) --> (http://bugs.winehq.org/attachment.cgi?id=18596) Add secure connections tests to test suite - use HeapAlloc()
I've attached a revised patch using HeapAlloc() and HeapFree().
Hmm, does wiki.winehq.org work better?
Unfortunately not. It looks like it is on a similarly configured server. They can be tested with a browser.
On a side-note it seems those servers are mis-configured since the response code is 200 (OK) whereas the page itself reports it as being 400 (BAD_REQUEST).
http://bugs.winehq.org/show_bug.cgi?id=16831
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=16831
Stu Hood stuhood@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stuhood@gmail.com
--- Comment #27 from Stu Hood stuhood@gmail.com 2009-09-28 01:47:20 --- I just used this patch successfully against f3b9fb554dd116c881422098738a1f0223087cd1 in order to use the Audible Manager, so I thought I'd vouch for it.
http://bugs.winehq.org/show_bug.cgi?id=16831
FC Truter fc.truter@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fc.truter@gmail.com
--- Comment #28 from FC Truter fc.truter@gmail.com 2009-10-13 09:49:25 --- Any idea on when this patch will be applied to the main version of wine? Patching and recompiling wine is a bit above my head, but I would still like to use audible.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #29 from FC Truter fc.truter@gmail.com 2009-10-14 04:44:53 --- I did apply this patch to Wine and it seems to work, but after i input my username/password, I receive a message saying that I have reached my limit of simultaneous activations and to contact their support. I checked on the website and I could add devices there just fine. I then tried to deactivate the Nero Plugin to no avail since it says it isn't activated. Any suggestions?
http://bugs.winehq.org/show_bug.cgi?id=16831
Elver Loho elver.loho@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |elver.loho@gmail.com
--- Comment #30 from Elver Loho elver.loho@gmail.com 2010-01-07 03:51:03 --- Just wanted to confirm that this patch works fine against 1.1.35 on Ubuntu and I got AudibleManager working thanks to it. Looking forward to the patch being included in the next release.
http://bugs.winehq.org/show_bug.cgi?id=16831
Mark Smith mhs@hp.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mhs@hp.com
--- Comment #31 from Mark Smith mhs@hp.com 2010-05-22 09:32:01 --- A similar error can be observed with IE 7.0 when configured to use an HTTP proxy.
err:wininet:NETCON_secure_connect SSL_connect failed: 12157
Specifically, the browser fails to submit the HTTPS form at the following URL (provided for Wine testing purposes) : https://www.rooms.hp.com/attend/default.aspx?key=RHNUUYAGFU
http://bugs.winehq.org/show_bug.cgi?id=16831
Reece Dunn msclrhd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |msclrhd@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=16831
Niklas nallroggen@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nallroggen@web.de
--- Comment #32 from Niklas nallroggen@web.de 2010-08-23 09:27:01 --- The patch worked with Audible Manager 5.5.0.4 and wine 1.2 stable. Only the "Add secure connections tests to test suite" patch does not worked. Registering and listening to files works fine.
http://bugs.winehq.org/show_bug.cgi?id=16831
Pedro Sol sol.lima@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sol.lima@gmail.com
--- Comment #33 from Pedro Sol sol.lima@gmail.com 2010-09-12 09:02:18 CDT --- Hi, can anyone tells me how exactly I can apply the patch? Thanks, Pedro Sol
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #34 from Juan Lang juan_lang@yahoo.com 2010-09-13 10:28:20 CDT --- (In reply to comment #33)
Hi, can anyone tells me how exactly I can apply the patch?
Not here, it's not a support forum. (Hint: read the FAQ.) Ask on wine-users if you need help.
http://bugs.winehq.org/show_bug.cgi?id=16831
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #35 from Dan Kegel dank@kegel.com 2010-10-02 10:44:17 CDT --- Looks like this blog post http://volatile-minds.blogspot.com/2010/09/audible-manager-on-ubuntu-require... points to a version updated for 1.3.3: http://files.volatileminds.net/misc/audible_wine-1.3.3.patch
TJ, did you ever submit your test patch to wine-patches? Be sure to include your real name.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #36 from TJ winehq@tjworld.net 2011-01-14 10:44:58 CST --- The patches didn't go further since there was no further feedback regarding a correctly configured HTTPS host for the test suite functions.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #37 from Dan Kegel dank@kegel.com 2011-01-14 11:14:00 CST --- I can think of two options. You could just pick some public https server, like gmail.com, and mark your test interactive so it's not run normally. Or you could bundle an https server with your test code. Both are reasonable options.
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #38 from TJ winehq@tjworld.net 2011-01-14 18:07:50 CST --- I no longer have an interest in this issue but if someone else wants to port it forward to the latest trunk, feel free.
http://bugs.winehq.org/show_bug.cgi?id=16831
Pavel Ondracka pavel.ondracka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pavel.ondracka@gmail.com
--- Comment #39 from Pavel Ondracka pavel.ondracka@gmail.com 2011-03-23 10:44:16 CDT --- The Witcher registration is also affected by this bug, winetricks wininet works around it.
err:wininet:NETCON_secure_connect SSL_connect failed: 12037
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #40 from Juan Lang juan_lang@yahoo.com 2011-03-23 13:57:06 CDT --- (In reply to comment #39)
The Witcher registration is also affected by this bug, winetricks wininet works around it.
err:wininet:NETCON_secure_connect SSL_connect failed: 12037
This is probably a different bug, even though the same function call fails. Please open a different bug for this, and attach a +wininet,+chain log to it.
http://bugs.winehq.org/show_bug.cgi?id=16831
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Summary|NETCON_secure_connect |Audible Manager fails to |SSL_connect failed |active device Ever Confirmed|0 |1
--- Comment #41 from Juan Lang juan_lang@yahoo.com 2011-03-23 14:01:12 CDT --- Adjusting summary to make clear it's not about other applications, and confirming from multiple comments about it.
http://bugs.winehq.org/show_bug.cgi?id=16831
Damian Ivanov damianatorrpm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damianatorrpm@gmail.com
--- Comment #42 from Damian Ivanov damianatorrpm@gmail.com 2011-08-27 04:32:23 CDT --- patch does not compile with 1.3.27 but did with 1.3.26
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #43 from Dan Kegel dank@kegel.com 2011-12-18 19:18:56 CST --- I can activate audible manager just fine (Devices / Activate), but I haven't tried activating a mobile device with it. What were the exact mouse or keyboard actions to reproduce this bug, again?
http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #44 from Damian Ivanov damianatorrpm@gmail.com 2012-06-26 02:17:29 CDT --- Is this still an issue n 1.5.6 or newer?
http://bugs.winehq.org/show_bug.cgi?id=16831
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #45 from Dan Kegel dank@kegel.com 2012-06-26 02:21:06 CDT --- Looks like it's been fixed for a while.
http://bugs.winehq.org/show_bug.cgi?id=16831
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #46 from Alexandre Julliard julliard@winehq.org 2012-07-03 14:13:57 CDT --- Closing bugs fixed in 1.5.8.
-
wine-bugs＠winehq.org