Error during connection to game lobby

[ayyad1231]

Hello, I am having an issue connecting to the 0 A.D. multiplayer lobby. I always get the error “The stream has been closed by the server.” I am using Windows 10, and my friends with the same game version can connect normally, even sometimes on the same network, but it does not work for me. I tested the connection and confirmed that the server is reachable (ping works), I already tried disabling and resetting the firewall, resetting the network (winsock, IP, DNS), and reinstalling the game, but nothing fixed the problem. I don’t understand why it only affects my computer. Any help would be appreciated.

[Stan`]

Have you enabled tls in the game options?

[Dunedan]

 

[ayyad1231]

The default configuration already has TLS enabled, but it isn’t working properly. The issue seems to be related to other problem I think.

[Dunedan]

Ok, this is a different problem then.

[ayyad1231]

Please did you have any proposition about solving this problem, I think that the server rejects me but I don't know why, I tried to disable firewall, I used Wireshark to see the network packets, and I see that the connection established then closed.

[Dunedan]

The account "tata12" is not registered. So if you tried to log in with that user account, that's probably the reason why it's not working, even though you should get a different error message in that case.

[ayyad1231]

But in this step I try to create this account. but the registration does not work.

[Shad_]

I had this problem recently, it might be your issue.

I have many security certificates installed by various programs in my Windows 10 Personal Store.  When 0AD tries to connect, it uses wrong info from the first 'valid' certificate it finds, whereas having none at all connects fine.  Reinstalling Windows, Creating a new Windows user or removing the certificates in the Windows 10 Personal Store does the same thing to fix that issue.  To check, just hit Win+R and type certmgr.msc and look at the Personal/Certificates folder.  If you have  certs in there, it may be the issue.  I was able to back them up and remove them to test it out. How to back up security certificates

May be an issue with how mTLS interacts with Windows

  

[Dunedan]

That's quite helpful. Here is my current theory what's happening:

While we don't use mTLS, there is support for that in ejabberd (the XMPP server we're using for the multiplayer lobby). Part of that is instructing the client (0ad) to optionally send a client certificate if it has one available (SSL_VERIFY_PEER option for SSL_CTX_set_verify of OpenSSL). For most Windows users that's not the case, as they never used client certificates. However, for users which have client certificates installed, SChannel (the TLS-library used by 0ad under Windows) picks an invalid certificate and sends it to the server under certain circumstances. As it's invalid the connection gets terminated, resulting in errors when trying to connect to the lobby. As sending a client certificate to the server is optional and not used by us, that should be an avoidable problem.

@Shad_: Could you do me a favor and figure out what's considered a valid client certificate by SChannel in this case? Is it just any client certificate or does it have to have certain properties (like being issued by Let's Encrypt for example). That would help us to find a way to work around the issue in 0ad or the lobby server so users don't have to manually take action.

[Stan`]

IIRC it also happened when users had smart cards. I remember some people sharing random popups while trying to connect.

[Dunedan]

12 hours ago, Stan` said:

IIRC it also happened when users had smart cards. I remember some people sharing random popups while trying to connect.

For reference: https://gitea.wildfiregames.com/0ad/0ad/issues/5396 

I believe it's likely that this is caused by the same underlying problem.

[hyperion]

Quick look at the gloox sources there is no explicit handling of client certs at all. Also https://learn.microsoft.com/en-us/windows/win32/secauthn/performing-authentication-using-schannel suggest Windows only looks for client certs if the server actually asks. Maybe you can configure ejabbered to not do that.

[Dunedan]

 

23 hours ago, Dunedan said:

However, for users which have client certificates installed, SChannel (the TLS-library used by 0ad under Windows) picks an invalid certificate and sends it to the server under certain circumstances. As it's invalid the connection gets terminated, resulting in errors when trying to connect to the lobby.

That theory turned out to be wrong, as I was able to confirm with "openssl client" that providing a self-signed and therefore invalid certificate to the lobby server works just fine. ejabberd in our configuration does just ignore any client certificate provided.

4 hours ago, hyperion said:

Also https://learn.microsoft.com/en-us/windows/win32/secauthn/performing-authentication-using-schannel suggest Windows only looks for client certs if the server actually asks. Maybe you can configure ejabbered to not do that.

Disabling requesting client certificates would be a workaround, but doesn't appear to be possible with ejabberd.

Seems like SChannel is doing something weird, as my understanding is that the client code terminates the connection after the TLS connection got established, not ejabberd. The best way forward is probably somebody debugging this who's running Windows.

[Shad_]

I thought it might be a TLS issue, as Wireshark showed a difference between a problem connection:

142.132.137.205	192.168.0.221	TLSv1.2	827	Certificate, Server Key Exchange, Certificate Request, Server Hello Done
192.168.0.221	142.132.137.205	TLSv1.2	1341	Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message

vs a successful connect:

142.132.137.205	192.168.0.221	TLSv1.2	828	Certificate, Server Key Exchange, Certificate Request, Server Hello Done
192.168.0.221	142.132.137.205	TLSv1.2	154	Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

the difference being that for the problem connection, the client responds to the "Certificate Request" with "Certificate Verify".

For a successful connection, it might be normal for Schannel to not send this back when the certificates are removed (or a user didn't have any in the first place), I am not familiar with Schannel and TLS1.2 responses.  Does the default.cfg setting verify_certificates have anything to do with the certificate request?  I've tried both true and false settings.

I did try adding the certificates back one at a time, and I no longer have the problem with any certificate, if one was a problem.  It had been a long while since I connected with and older version of 0AD before upgrading to the new one.  Maybe a cache was corrupted somehow, and maybe clearing that cache (through inetcpl.msc)? may work, but I can no longer duplicate the problem to test this.  I had 9 certs, only 1 with a key, and 1 expired, but again, adding them back in did not duplicate the issue.

 

Edited 53 minutes ago by Shad_

[Dunedan]

22 minutes ago, Shad_ said:

the difference being that for the problem connection, the client responds to the "Certificate Request" with "Certificate Verify".

For a successful connection, it might be normal for Schannel to not send this back when the certificates are removed (or a user didn't have any in the first place), I am not familiar with Schannel and TLS1.2 responses.

Yes, the client can only send a "Certificate Verify" if it has a client certificate available. So this just indicates whether a client certificate is available or not and isn't directly related to the problem. When using "openssl client" with a client certificate "Certificate Verify" is included as well and the connection succeeds without issues

26 minutes ago, Shad_ said:

I did try adding the certificates back one at a time, and I no longer have the problem with any certificate, if one was a problem.

Thanks for checking anyway. Much appreciated.