Opened 7 years ago
Last modified 13 months ago
#4705 closed enhancement
Use TLS for multiplayer lobby — at Version 20
Reported by: | rugk | Owned by: | |
---|---|---|---|
Priority: | Must Have | Milestone: | Alpha 27 |
Component: | Multiplayer lobby | Keywords: | |
Cc: | Patch: |
Description (last modified by )
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).
Report by leper on Sep 7th 2013: https://github.com/JoshuaJB/0ad/issues/3
Change History (20)
comment:1 by , 7 years ago
Milestone: | Backlog |
---|---|
Resolution: | → invalid |
Status: | new → closed |
comment:2 by , 7 years ago
Description: | modified (diff) |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
Summary: | Use HTTPS for multiplayer lobby → Use TLS for multiplayer lobby |
Edited.
comment:3 by , 7 years ago
Component: | Network → Multiplayer lobby |
---|
Please let someone else manage this issue.
comment:4 by , 6 years ago
Keywords: | security multiplayer removed |
---|---|
Milestone: | → Backlog |
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.
comment:5 by , 6 years ago
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.
comment:6 by , 6 years ago
Milestone: | Backlog → Alpha 23 |
---|
comment:7 by , 6 years ago
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.
comment:8 by , 6 years ago
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).
comment:9 by , 6 years ago
In that case we probably use WinTLS which is the default for windows and if Im not mistaken not supported for WindowsXP.
comment:10 by , 6 years ago
Milestone: | Alpha 23 → Backlog |
---|
Certificate and server are correct, gloox doesn't implement certificate verification incorrectly and rejects the certificate: https://bugs.camaya.net/ticket/?id=280
comment:11 by , 6 years ago
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.
comment:13 by , 6 years ago
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 fromModIO.cpp
(https://api.mod.io/
) andUserReporter.cpp
(when changing the upload url tohttps://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 forgloox
norlibCURL
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.
comment:14 by , 6 years ago
Description: | modified (diff) |
---|
comment:16 by , 6 years ago
Itms tested 0 A.D. on Windows XP, found that libCURL complains about outdated TLS support and gloox connects as expected (ignoring certs).
comment:19 by , 5 years ago
TLS 1.0 should be disabled serverside, because it is prone to BEAST attacks. However the Windows client currently requires that version.
comment:20 by , 5 years ago
Description: | modified (diff) |
---|
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.