Use TLS for multiplayer lobby

[rugk]

TLS should be used in the lobby in order to protect passwords.

Threat model: Any network attacker; three-letter agency or attacker in wifi

Edit: SSL is considered a requirement since May 25th 2018 following GDPR article 32.1.a ​https://gdpr-info.eu/art-32-gdpr/ (and there already have been Cease&Decist letter for trivial contact forms not using SSL).

[leper]

TLS, not HTTPS. Since the rest of the ticket is quite wrong based on that confusion I'm closing this as invalid. If you care about rewriting that into seomething sensible reopen it, also there is a multiplayer lobby component.

[rugk]

Edited.

[rugk]

Please let someone else manage this issue.

[Itms]

Just a note for the future work on this: gloox will have to be compiled with gnutls (or possibly openssl, but gnutls is the default) and anonymous authentication is currently broken with gnutls >= 3.6.0 (see #5033 and the related openSUSE bug). This might be fixed when we work on this.

[elexis]

TLS enabled in r21875.

As mentioned in #5033 I only see the gloox unit tests being affected, so this should not affect 0 A.D. code in any way on any platform. I also only see the choice between OpenSSL and GnuTLS in the INTALL file and online FAQ, but no choice to compile without any TLS support. I asked Imarok who built the last gloox binary to confirm.

[elexis]

Problem.

TLS does seem to work with TLS according to Angens test yesterday.

That means the windows gloox binary comes with either with GnuTLS or OpenSSL.

According to Itms uncertain comments in #5033, it does not use GnuTLS.

Philip posted a comment the next day on IRC that noone cared about:

2018-02-13-QuakeNet-#0ad-dev.log:

13:37 < Philip> Itms: Regarding the OpenSSL thing: You might need to check that the OpenSSL license is compatible with GPL (v3 for Gloox, I think?) - I vaguely remember there being problems in the past, and I don't know if they've been resolved yet

13:38 < Philip> See e.g. ​https://lwn.net/Articles/428111/

So it seems we need a new gloox binary because we have violated a license all the time.

[Itms]

I do not know about gloox, but libcurl on Windows gets TLS support from a library (called winssl if my memory is correct) provided by the platform. Maybe the same thing is used by gloox by default on Windows. In any case we are not using gnutls nor openssl to build gloox on Windows (maybe I wasn't the last one to update it but when I did I didn't use either of these libs, and I assume other people have followed the same instructions as I did).

[elexis]

In that case we probably use WinTLS which is the default for windows and if Im not mistaken not supported for WindowsXP.

[elexis]

Certificate and server are correct, gloox doesn't implement certificate verification incorrectly and rejects the certificate: ​https://bugs.camaya.net/ticket/?id=280

[rugk]

So the error is "unknown certificate issuer".

Are you sure you actually tested it on a system, where either the Let's Encrypt root certificate or the "IdenTrust DST Root CA X3" are included? Because when they are not, that would result in such an error. See ​https://letsencrypt.org/certificates/ for the details.

[elexis]

See link (as in yes)

[elexis]

Solved: Licensing
Issues: Windows XP support dropped? gloox broken.

I guess you wanted to hear the story:

• So it seems we use SChannel implementation on Windows builds and GnuTLS on unix builds.
• Therefore no GPL v3 licensing issue with OpenSSL.
• But we might have dropped Windows XP without noticing, as SChannel is either not or not well supported there.

Certificate Verification:

• Since the Let's Encrypt certificate was installed, the certificate verification still failed on Windows (user1) and Ubuntu (mine) but not Debian/unstable (Dunedan).
• In ​Phab:D1620 the certificate error strings were displayed from gloox and it said the Issuer (Let's Encrypt) was not recognized.
• The Let's encrypt certificate was correctly installed according to the manual.
• ejabberd documentation says it serves certificate chains well.
• wireshark confirms that ejabberd sends a certificate chain containing the Let's Encrypt root CA cert signed by IdenTrust and the lobby certificate signed by Let's Encrypt.
• libCURL in 0 A.D. accepts the Let's Encrypt certificate from ModIO.cpp (https://api.mod.io/) and UserReporter.cpp (when changing the upload url to https://play0ad.com/)
• That already indicates that the error should be searched in the gloox code and how it uses GnuTLS and SChannel.
• The rootCA was in my directory and also adding the Lets Encrypt rootCA didn't change the result.
• The gnutls-cli app works as intended with https but didn't establish a connection to xmpp (although it claims it can).
• Joining jabber.de with 0 A.D. works, but also rejects the cert. Half of all Xmpp servers I found use Lets Encrypt.
• Installing the most recent gloox version didn't change the result.
• Setting the GNUTLS debugging level also didn't show anything relevant.
• Since it was a trust issue, looking at how gloox reads the root certificate authority certificates that the operating system trusts revealed the issue in gloox. Namely that it doesn't read any.
• libCURL code hardcodes certificate paths like /etc/ssl/certs/, that's not an option for us (nor advisable for gloox nor libCURL since it's the OS decision which certs to trust).
• Browsing through the GnuTLS specifications shows gnutls_certificate_set_x509_system_trust should be used to load the OS certificates. Doing so fixes the Issuer bug.
• Then there's a wrong negation in the gloox GnuTLS client code. If both are fixed, the certificate is accepted. Hence the patch uploaded to ​https://bugs.camaya.net/ticket/?id=280
• The gloox GnuTLS implementation also doesn't seem to pass on the given caCerts in the constructor, but I don't want to go down that rabbithole too.
• The gloox GnuTLS code seems about untouched since 2012 before the gnutls_certificate_set_x509_system_trust command became available. But that's a discussion for the gloox bugtracker.
• Since the certificate is rejected on the Windows build as well and since we assume SChannel is used, the gloox SChannel implementation may be assumed broken as well.
• Once upstream gloox/GnuTLS bug is fixed, we may rebuild the Windows gloox library with GnuTLS if that's the case.