Recently Added

Notes & Bookmarks

  1. Quasars; power and metrics beyond all comprehension. Staggeringly beautiful information... and very well written.
  2. "I'm sorry. I can't come in today. Religious holiday. The feast of...Maximum Occupancy."pic.twitter.com/mkgxPWfNj2
  3. Verifying myself: I am sgnls on Keybase.io. UJa01G4v3YRJYB1LFjDRSf1Nh0bh1sOykCbq / https://keybase.io/sgnls/sigs/UJa01G4v3YRJYB1LFjDRSf1Nh0bh1sOykCbq
  4. Be sure to take care of your own infrastructure(s); purge dumps, tunnel and lock-down egress transit, encrypt and permission CORRECTLY!
  5. It really doesn't matter what else gets released; Sikth's 'The Future in Whose Eyes?' is THE album of 2017. #albumoftheyear @SikthOfficialpic.twitter.com/P5houdf1yx

HTTP(s) Issues w/ Wine32/64 (Steam, uPlay etc.)

Updated : 15:43:10pm, 11th Feb 2017

This is a copy (for my sake) of a thread I've started on the WineHQ forums.

It's a well documented problem but I am unsure of what correlation(s) have been made previously. Intention of this thread is to progress with further debugging.

When run with wine32/64, Steam is capable of negotiating HTTP sessions, but often verbose output flags 'fixme' issues with WINHTTP / proxy complaints etc.

Pertinent to Steam, 'steamwebhelper.exe' crashes when loading certain pages (i.e. 'Friends', 'Community' etc.), but the Steam application remains functional. AFAIK, this behaviour has existed in Wine versions ~1.6+ (don't take that as concrete) and is 'intermittent'. There does not appear to be any degradation with online game-play that I've tested (e.g. CoD:MW2 plays flawlessly).

I have since installed uPlay and a similar behaviour is demonstrated; running against a clean prefix install at ~/.wine (created with wine32), uPlay opens and I can verify network communication attempts to establish;

17:23:06.516279 IP lb-upc-dmx.ubisoft.com.https > niflheim.47486: Flags [F.], seq 2167957051, ack 2135927606, win 8256, length 0
17:23:06.516738 IP niflheim.35866 > edea.domain: 24871+ PTR? 188.48.98.216.in-addr.arpa. (44)
17:23:06.517264 IP niflheim.47486 > lb-upc-dmx.ubisoft.com.https: Flags [F.], seq 1, ack 1, win 251, length 0
17:23:06.541923 IP edea.domain > niflheim.35866: 24871 1/0/0 PTR lb-upc-dmx.ubisoft.com. (80)
17:23:06.621598 IP lb-upc-dmx.ubisoft.com.https > niflheim.47486: Flags [.], ack 2, win 8256, length 0
17:23:07.110997 IP niflheim.35368 > edea.domain: 49785+ A? public-ubiservices.ubi.com. (44)
17:23:07.134653 IP edea.domain > niflheim.35368: 49785 2/0/0 CNAME public.aws-ubiservices.ubi.com., A 216.98.62.46 (97)
17:23:07.135362 IP niflheim.51482 > local62-mtl-46.ubisoft.qc.ca.https: Flags [S], seq 3789811482, win 29200, options [mss 1460,sackOK,TS val 26404340 ecr 0,nop,wscale 7], length 0

Despite potential fragmentation issues (which will cause issues with TCP sessions, especially if encapsulation, i.e. SSL/TLS, is involved);

17:23:07.349964 IP edea > niflheim: ICMP local62-mtl-46.ubisoft.qc.ca unreachable - need to frag (mtu 1492), length 556

I believe the source of issue(s) and their intermittent nature is due to the negotiation handshakes available on the presented termination;

fixme:ras:RasEnumConnectionsW (0x5703cd8,0x4a8fac4,0xa260004),stub!
fixme:ras:RasEnumConnectionsW RAS support is not implemented! Configure program to use LAN connection/winsock instead!
fixme:secur32:schannel_get_kx_algid unknown algorithm 12

TLS is being offered outright by failing nodes;

e.g. local62-mtl-29.ubisoft.qc.ca (uPlay)

$ nmap --script ssl-enum-ciphers -p 443 local62-mtl-29.ubisoft.qc.ca
Nmap scan report for local62-mtl-29.ubisoft.qc.ca (216.98.62.29)
Host is up (0.10s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Weak cipher RC4 in TLSv1.1 or newer not needed for BEAST mitigation
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Weak cipher RC4 in TLSv1.1 or newer not needed for BEAST mitigation
|_  least strength: C

e.g. a23-205-213-78.deploy.static.akamaitechnologies.com (Steam)

$ nmap --script ssl-enum-ciphers -p 443 a23-205-213-78.deploy.static.akamaitechnologies.com
Nmap scan report for a23-205-213-78.deploy.static.akamaitechnologies.com (23.205.213.78)
Host is up (0.016s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C

In essence, the crash / inability to establish a secure connection happens via connections over TLS1.x as opposed to those offering SSL1/2x.

I may well be wide of the mark, or this might be common knowledge, but I've made a point to open discussion here just in case, even if only for myself :)

n.b. I am (currently) unaware how much of an overlap this has with existing workaround(s) with the crypt32.dll patches and overrides via winetricks, but I am confident they are related (this DLL and orphan libraries are those used in SSL/TLS negotiation in Windows, after all).

--##--

$ wine --version
wine-1.9.8 (Staging)

$ rpm -qa | grep wine
wine-systemd-1.9.8-1.fc23.noarch
wine-alsa-1.9.8-1.fc23.i686
wine-arial-fonts-1.9.8-1.fc23.noarch
wine-openal-1.9.8-1.fc23.i686
wine-system-fonts-1.9.8-1.fc23.noarch
wine-desktop-1.9.8-1.fc23.noarch
wine-ldap-1.9.8-1.fc23.x86_64
wine-mono-4.6.2-1.fc23.noarch
mingw32-wine-gecko-2.44-1.fc23.noarch
wine-pulseaudio-1.9.8-1.fc23.x86_64
wine-courier-fonts-1.9.8-1.fc23.noarch
wine-ldap-1.9.8-1.fc23.i686
wine-filesystem-1.9.8-1.fc23.noarch
wine-core-1.9.8-1.fc23.x86_64
wine-ms-sans-serif-fonts-1.9.8-1.fc23.noarch
wine-pulseaudio-1.9.8-1.fc23.i686
wine-twain-1.9.8-1.fc23.x86_64
wine-common-1.9.8-1.fc23.noarch
wine-marlett-fonts-1.9.8-1.fc23.noarch
wine-core-1.9.8-1.fc23.i686
wine-cms-1.9.8-1.fc23.i686
wine-symbol-fonts-1.9.8-1.fc23.noarch
wine-fonts-1.9.8-1.fc23.noarch
wine-twain-1.9.8-1.fc23.i686
wine-openal-1.9.8-1.fc23.x86_64
wine-small-fonts-1.9.8-1.fc23.noarch
wine-opencl-1.9.8-1.fc23.x86_64
wine-times-new-roman-fonts-1.9.8-1.fc23.noarch
wine-wingdings-fonts-1.9.8-1.fc23.noarch
wine-cms-1.9.8-1.fc23.x86_64
wine-opencl-1.9.8-1.fc23.i686
wine-fixedsys-fonts-1.9.8-1.fc23.noarch
wine-capi-1.9.8-1.fc23.i686
wine-1.9.8-1.fc23.i686
wine-tahoma-fonts-1.9.8-1.fc23.noarch
wine-alsa-1.9.8-1.fc23.x86_64
wine-capi-1.9.8-1.fc23.x86_64

SGNLS.net © 2006-2017

Comments, submissions and errors to desk[at]sgnls.net.

Material and content adheres to the Creative Commons (NC-SA 4.0) license.

v12.01151