Summary: | app-misc/ca-certificates-20200601.3.53 breaks some Steam games | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tomasz Golinski <tomaszg> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | a.zuber, sam, techwolf.lupindo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | output of ssldump (truncated as it was too large) |
Description
Tomasz Golinski
2020-06-05 21:55:27 UTC
Created attachment 643572 [details]
output of ssldump (truncated as it was too large)
There isn't any actual failure in this ssldump log, but ssldump is also really outdated. 198.20.198.110 serves up LIVE-SERVICES.ELDERSCROLLSONLINE.COM as the default certificate. It might have other responses but your logs don't contain enough detail to show SNI. That cert was issued by DigiCert, and is fine. curl connects fine to that IP/hostname, with both versions of ca-certificates. If you captured raw tcpdump packets, try play them through wireshark's text version "tshark -V", or attach here. Can you also try ca-certificates-20190110.3.53? Just want to rule where the problem was introduced. The attached log was of successful connection. On "bad" version I don't see anything in ssldump. ca-certificates-20190110.3.53 work fine for me. I just tried experimenting with dumps again and I'm probably too stupid to understand what I'm doing. I tried again the bad certs and I don't see ANYTHING in tcpdump when the launcher starts other than my local network traffic, google dns queries and Steam talk on 155.133.230.50. However this Steam talk shows only when I start the game and stops long before launcher shows up. While it is "loading" I don't see any tcpdump activity at all. In the case of good certs, after Steam chatter, I see a HTTP connection to 159.100.230.100 (which is Bethesda/Zenimax server, as expected) and it then moves to 198.20.198.110 via HTTPS (also Zenimax server). I don't see any packages sent to any of those IPs with bad cert package. Here's an example of bad run: tcpdump host not \( htpc or dns.google \) dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 19:45:23.520179 IP 192.168.2.1.46325 > 155.133.230.50.27025: Flags [P.], seq 3579209299:3579209404, ack 711374898, win 32406, options [nop,nop,TS val 3797168361 ecr 1181998594], length 105 19:45:23.520533 IP 192.168.2.1.46325 > 155.133.230.50.27025: Flags [P.], seq 105:393, ack 1, win 32406, options [nop,nop,TS val 3797168362 ecr 1181998594], length 288 19:45:23.524085 IP 155.133.230.50.27025 > 192.168.2.1.46325: Flags [.], ack 393, win 1027, options [nop,nop,TS val 1182007383 ecr 3797168361], length 0 19:45:23.772835 IP 155.133.230.50.27025 > 192.168.2.1.46325: Flags [P.], seq 1:187, ack 393, win 1027, options [nop,nop,TS val 1182007632 ecr 3797168361], length 186 19:45:23.772846 IP 192.168.2.1.46325 > 155.133.230.50.27025: Flags [.], ack 187, win 32406, options [nop,nop,TS val 3797168614 ecr 1182007632], length 0 19:45:23.819675 IP 155.133.230.50.27025 > 192.168.2.1.46325: Flags [P.], seq 187:470, ack 393, win 1027, options [nop,nop,TS val 1182007679 ecr 3797168614], length 283 19:45:23.819685 IP 192.168.2.1.46325 > 155.133.230.50.27025: Flags [.], ack 470, win 32406, options [nop,nop,TS val 3797168661 ecr 1182007679], length 0 19:45:25.743179 IP 192.168.2.1.46325 > 155.133.230.50.27025: Flags [P.], seq 393:507, ack 470, win 32406, options [nop,nop,TS val 3797170584 ecr 1182007679], length 114 19:45:25.796383 IP 155.133.230.50.27025 > 192.168.2.1.46325: Flags [.], ack 507, win 1027, options [nop,nop,TS val 1182009656 ecr 3797170584], length 0 19:45:26.522860 IP 155.133.230.50.27025 > 192.168.2.1.46325: Flags [P.], seq 470:638, ack 507, win 1027, options [nop,nop,TS val 1182010382 ecr 3797170584], length 168 19:45:26.522877 IP 192.168.2.1.46325 > 155.133.230.50.27025: Flags [.], ack 638, win 32406, options [nop,nop,TS val 3797171364 ecr 1182010382], length 0 ^C 11 packets captured 15 packets received by filter 0 packets dropped by kernel -------------------------------------------------------- From time to time some packets to Akamai servers (2.22.119.11, 104.81.127.75, 72.247.182.163) pop up via HTTPS, but not always. Can't find a pattern. Might be some things Steam uses for extra security. According to https://www.protondb.com/app/306130 some people on Debian also had this problem. Oh wow, oh wow. Found this bug after not being able to update ESO online for a few days. After much furpulling, I figure out the root cause. What is causing the Launcher to "hang" at "Loading..." is a sig check of MinSpecDetectionInterop.dll failure. From the host.developer.log log. 06/16/2020 20:06:21 Loading interop library (C:\Program Files (x86)\Steam\steamapps\common\Zenimax Online\Launcher\MinSpecDetectionInterop.dll) (1.0.0.1) 06/16/2020 20:06:21 Certificate not trusted by trust provider 06/16/2020 20:06:21 Library validation (C:\Program Files (x86)\Steam\steamapps\common\Zenimax Online\Launcher\MinSpecDetectionInterop.dll) failed I looked at the file on my backup ESO install on a win7 laptop. That file is signed with Zenimax Media Inc. with a CN of "thawte SHA256 Code signing CA" Serial number of 71a0b73695ddb1afc23b2b9a18ee54cb of the CA signer. I think I found the cause. Three files are missing in the upgrade. /usr/share/ca-certificates/mozilla/thawte_Primary_Root_CA.crt /usr/share/ca-certificates/mozilla/thawte_Primary_Root_CA_-_G2.crt /usr/share/ca-certificates/mozilla/thawte_Primary_Root_CA_-_G3.crt During the build of app-misc/ca-certificates-20200601.3.53::gentoo, I notice this: Certificate "thawte Primary Root CA" blacklisted, ignoring. Certificate "thawte Primary Root CA - G2" blacklisted, ignoring. Certificate "thawte Primary Root CA - G3" blacklisted, ignoring. The missing certs is what causing ESO online game Launcher/patcher failure to fully start. Info at https://knowledge.digicert.com/generalinformation/INFO2172.html suggest that "thawte Primary Root CA" is needed for "thawte SHA256 Code signing CA". (In reply to Techwolf from comment #5) > I think I found the cause. Three files are missing in the upgrade. > > /usr/share/ca-certificates/mozilla/thawte_Primary_Root_CA.crt > /usr/share/ca-certificates/mozilla/thawte_Primary_Root_CA_-_G2.crt > /usr/share/ca-certificates/mozilla/thawte_Primary_Root_CA_-_G3.crt > > During the build of app-misc/ca-certificates-20200601.3.53::gentoo, I notice > this: > > Certificate "thawte Primary Root CA" blacklisted, ignoring. > Certificate "thawte Primary Root CA - G2" blacklisted, ignoring. > Certificate "thawte Primary Root CA - G3" blacklisted, ignoring. > > The missing certs is what causing ESO online game Launcher/patcher failure > to fully start. > > Info at https://knowledge.digicert.com/generalinformation/INFO2172.html > suggest that "thawte Primary Root CA" is needed for "thawte SHA256 Code > signing CA". Thanks for the extensive digging. I can tell you WHY those certs are gone now: These are the Symantec related CAs that were removed because Symantec failed SSL audit requirements. https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/FLHRT79e3XE/90qkf8jsAQAJ https://wiki.mozilla.org/CA:Symantec_Issues So now I'm not sure what the best course of action here is. Games on steam are unlikely to get that file re-signed. The Official recommendations on Bethesda forums for windows are basically get that CA cert added back to the Windows Cert store by horrible hackery. I don't know if there is a good way to override the certs for JUST one game either. @TechWolf & others: The old ca-certificate packages have been removed from the tree now. If you still need specific now-removed certificates for Steam games, you should add those certificates to /usr/local/share/ca-certificates and then run update-ca-certificates. (In reply to Robin Johnson from comment #7) > @TechWolf & others: > The old ca-certificate packages have been removed from the tree now. > > If you still need specific now-removed certificates for Steam games, you > should add those certificates to /usr/local/share/ca-certificates and then > run update-ca-certificates. Just for clarification, in my case, copy /usr/share/ca-certificates/mozilla/thawte_Primary_Root_CA.crt and the two other files to said directory location. Update app-misc/ca-certificates package. Then run update-ca-certificates. Making sure I and others that find this bug though a search engine have a working workaround until its fixed upstream. For me, the game now works without any workarounds. However according to report on Valve's tracker, certificates-3.60 might break it again: https://github.com/ValveSoftware/Proton/issues/556#issuecomment-745458089 |