Reinstalling under Fedora 33

[trinic]

So I've disabled the firewall, reset my FF password a couple of times through the website, and tried searching for the SSL error, but nothing works. I'm using the install script from the Lutris site. Any ideas?

System.AggregateException: One or more errors occurred. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel. at System.Net.WebClient.UploadDataInternal(Uri address, String method, Byte[] data, WebRequest& request) at System.Net.WebClient.UploadString(Uri address, String method, String data) at XIVLauncher.Game.Launcher.RegisterSession(OauthLoginResult loginResult, DirectoryInfo gamePath) in D:\Sapphire\FFXIVQuickLauncher\XIVLauncher\Game\Launcher.cs:line 386 at System.Threading.Tasks.Task1.InnerInvoke() at System.Threading.Tasks.Task.Execute() --- End of inner exception stack trace --- at System.Threading.Tasks.Task1.GetResultCore(Boolean waitCompletionNotification) at XIVLauncher.Game.Launcher.Login(String userName, String password, String otp, Boolean isSteamServiceAccount, Boolean useCache, DirectoryInfo gamePath) in D:\Sapphire\FFXIVQuickLauncher\XIVLauncher\Game\Launcher.cs:line 132 at XIVLauncher.Windows.MainWindow.d__17.MoveNext() in D:\Sapphire\FFXIVQuickLauncher\XIVLauncher\Windows\MainWindow.xaml.cs:line 466 ---> (Inner Exception #0) System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel. at System.Net.WebClient.UploadDataInternal(Uri address, String method, Byte[] data, WebRequest& request) at System.Net.WebClient.UploadString(Uri address, String method, String data) at XIVLauncher.Game.Launcher.RegisterSession(OauthLoginResult loginResult, DirectoryInfo gamePath) in D:\Sapphire\FFXIVQuickLauncher\XIVLauncher\Game\Launcher.cs:line 386 at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute()<---

Version: 5.2.1.0 Git Hash: 0fc3088 Context: Login OS: Microsoft Windows NT 6.1.7601 Service Pack 1 64bit? True DX11? True Addons Enabled? True Auto Login Enabled? False Language: English LauncherLanguage: English Game path: C:\Program Files (x86)\SquareEnix\FINAL FANTASY XIV - A Realm Reborn

Addons: []

[reiichi001]

Hello!

Are you using the current Lutris installer or the older one that did manual updates?

Which version of the Lutris runner are you using? It's recommended to stick to lutris-5.7-11-x86_64 as the wine runner if possible as that one has been tested to work.

[trinic]

Nevermind - found my answer, I think. Just noticed this at the bottom of the Lutris page:

Under Fedora 33 game fails to launch after credentials are verified with ssl/tls error.

Fedora 33 implemented a crypto policy blocking sha1 tls/ssl 1.0/1.1 support.

To fix the ssl/tls handshake issue with Fedora 33: update-crypto-policies --set DEFAULT:FEDORA32

Should be done with sudo/root, and reboot.

[bekopharm]

Thanks for the find @trinic - was very confused when I enabled the debug log to find this error.

My understanding is that this is an issue with the target, e.g. the login system of SE, still using SHA-1 (and even TLS 1) that is broken since what… 2005?

https://en.wikipedia.org/wiki/SHA-1

Lowering the system wide cryptography standards for a game sounds very wrong to me. Also I expect this workaround to become unusable when gnutls simply won't support sha1 any more. The workaround would be to ship an older version with the installer.

FYI: This is not a Fedora specific issue. SHA1 deprecation is from my understanding on all roadmaps due to recent improved collision attacks.

Edith says:

Not sure what to make of this. Checked both, urls (ffxiv-login.square-enix.com, patch-gamever.ffxiv.com) and both report TLSv1.2 to me so mebbe it is the FFXIVQuickLauncher asking for 1.1?

[goaaats]

Hi, so SE servers on Windows are using TLS 1.2 with SHA256(excluding boot patches which are served via HTTP, and the ones that are HTTPS failing handshakes randomly, but that's beside the point) - I'm not a Linux/wine user, might the issue be that wine picks the lowest possible SSL version when going into native APIs?

If so, we can probably force 1.2.

[bekopharm]

@goaaats heh, I just updated mine. Good timing :+1:

[goaaats]

Yeah, just noticed - I think this is up to wine APIs behaving differently than Windows APIs since on Windows, it definitely picks TLS 1.2. We've noticed this before for updates on GitHub API servers since they only support 1.3 afaik.

Can't confirm this though.

[bekopharm]

Can reprodce this with gnutls 3.6.15. When policy is set to FEDORA32 I get:

gnutls-cli --priority-list @NORMAL -l | grep Protocols
Protocols: VERS-TLS1.0, VERS-TLS1.1, VERS-TLS1.2, VERS-TLS1.3, VERS-DTLS0.9, VERS-DTLS1.0, VERS-DTLS1.2

gnutls-cli patch-gamever.ffxiv.com
Processed 147 CA certificate(s).
Resolving 'patch-gamever.ffxiv.com:443'...
Connecting to '124.150.157.126:443'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=patch-gamever.ffxiv.com,OU=Information Technology Division,O=SQUARE ENIX CO.\, LTD.,L=Shinjuku-ku,ST=Tokyo,C=JP', issuer `CN=RapidSSL RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x06c8f896498015ac2904b9f4ae62a61a, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-02-11 00:00:00 UTC', expires `2021-03-01 12:00:00 UTC', pin-sha256="xdgy+AgjSbZS/kinRReH4tldlluvKExWhv0ZvLs5NrY="
    Public Key ID:
        sha1:ec41637c857f921e2aafb01eaa2e281713b57118
        sha256:c5d832f8082349b652fe48a7451787e2d95d965baf284c5686fd19bcbb3936b6
    Public Key PIN:
        pin-sha256:xdgy+AgjSbZS/kinRReH4tldlluvKExWhv0ZvLs5NrY=

- Certificate[1] info:
 - subject `CN=RapidSSL RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US', issuer `CN=DigiCert Global Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x08a5a246cd4b5c8c83d702b4bbab5349, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-11-06 12:23:33 UTC', expires `2027-11-06 12:23:33 UTC', pin-sha256="nKWcsYrc+y5I8vLf1VGByjbt+Hnasjl+9h8lNKJytoE="
- Status: The certificate is trusted. 
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
- Description: (TLS1.2-X.509)-(DHE-CUSTOM1024)-(RSA-SHA256)-(AES-128-GCM)

With default (Fedora 33) I get:

gnutls-cli --priority-list @NORMAL -l | grep Protocols
Protocols: VERS-TLS1.2, VERS-TLS1.3, VERS-DTLS0.9, VERS-DTLS1.2

gnutls-cli patch-gamever.ffxiv.com
Processed 147 CA certificate(s).
Resolving 'patch-gamever.ffxiv.com:443'...
Connecting to '124.150.157.126:443'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=patch-gamever.ffxiv.com,OU=Information Technology Division,O=SQUARE ENIX CO.\, LTD.,L=Shinjuku-ku,ST=Tokyo,C=JP', issuer `CN=RapidSSL RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x06c8f896498015ac2904b9f4ae62a61a, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-02-11 00:00:00 UTC', expires `2021-03-01 12:00:00 UTC', pin-sha256="xdgy+AgjSbZS/kinRReH4tldlluvKExWhv0ZvLs5NrY="
    Public Key ID:
        sha1:ec41637c857f921e2aafb01eaa2e281713b57118
        sha256:c5d832f8082349b652fe48a7451787e2d95d965baf284c5686fd19bcbb3936b6
    Public Key PIN:
        pin-sha256:xdgy+AgjSbZS/kinRReH4tldlluvKExWhv0ZvLs5NrY=

- Certificate[1] info:
 - subject `CN=RapidSSL RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US', issuer `CN=DigiCert Global Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x08a5a246cd4b5c8c83d702b4bbab5349, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-11-06 12:23:33 UTC', expires `2027-11-06 12:23:33 UTC', pin-sha256="nKWcsYrc+y5I8vLf1VGByjbt+Hnasjl+9h8lNKJytoE="
- Status: The certificate is trusted. 
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
*** Fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

I'm no expert on this but DHE-CUSTOM1024 seems to be the catch:

https://ldapwiki.com/wiki/Diffie-Hellman%20Ephemeral

The client offers a cipher suite in the ClientHello that includes DHE, and the server offers the client group parameters generator g and modulus p. If the client does not consider the group strong enough (e.g., p is too small, p is not prime, or there are small subgroups that cannot be easily avoided) or if it is unable to process the group for other reasons, the client has no recourse but to terminate the connection.

I wonder why they don't use ECDHE :thinking:

Anyway, the catch is that the target (SE) should probably raise that bar: https://www.gnutls.org/faq.html#prime-not-acceptable

More systems will follow break on this.

[reiichi001]

Per kainz0r#8272 on discord, this can be fixed by setting the dssenh dll override to native mode.

Please try setting an environment variable for dssenh=n or set it in Lutris like below. (If Lutris has set other env overrides, please keep those there)

I've also submitted this as an update to the Lutris script for xivlauncher pending review.

[dragynbane222]

Per kainz0r#8272 on discord, this can be fixed by setting the dssenh dll override to native mode.

Please try setting an environment variable for dssenh=n or set it in Lutris like below. (If Lutris has set other env overrides, please keep those there)

I've also submitted this as an update to the Lutris script for xivlauncher pending review.

This didn't work for me at all under Fedora 34. What did end up working is enabling LEGACY for crypto policies, probably not recommended.

Here's the command to do so for those who don't care about recommendations and are using Fedora: sudo update-crypto-policies --set LEGACY

I don't know how much of a security hole that opens (not a sysadmin or security researcher or anything of the sort).