Syncplay unofficial client and official server mutual TLS authentification

[yuroyami]

Today I have finally decided to experiment with adding TLS support to the Android unofficial client . I am not well-knowledgeable when it comes to SSL but I believe I grasp the notion well enough to understand how to implement the whole thing. As per the discussion here (Huge thanks to @Et0h and @daniel-123), I concluded that Syncplay uses (Opportunistic) mutual TLS where both the server and the client have to authenticate themselves to one other. The server presents its certificates to the Android client, which authenticates it against its own built-in CAs, all good so far, since LetsEncrypt is officially supported by Android. The client, in return, can present a set of certificates that cannot be self-signed, and have to be issued by trusted CA, be it global or private. Here lies the issue:

• Having the unofficial client connect via TLSv1.3 to the public servers is my main priority, since that's what most users use. However, in order to have the client prove to the public servers that it's valid, I assume it should present a set of certificates that are trusted by the server, which is not possible since I do not own the servers or the domains. Since self-signed certificates are not eligible in this case, this puts me by a roadblock. I may be understanding the entirety of this TLS procedure wrong. But I couldn't find any clues on how to make the client present trustable certificates that are not issued by, say, LetsEncrypt or ZeroSSL.

If this roadblock is overcome, I can further extend the TLS support beyond that, and make the client capable of loading .pem certificates within a folder (just like what Syncplay desktop expects), so a user can also connect his Android unofficial client to a custom private server.

TL;DR: I suspect the missing piece of the puzzle for an unofficial client to connect via TLS to the public servers is the server's certificates, correct ?

[daniel-123]

Hi @yuroyami - what you are describing is mutual TLS, Syncplay doesn't use it. In fact I'm somewhat surprised every time I hear somebody mention it who is not an IT security professional or developer/architect of large Kubernetes applications.

Syncplay only uses the "standard" TLS where client verifies that the certificate presented by the server is valid - the same basic principle as typical https website. If you for a second ignore the details of negotiating the opportunistic TLS by Syncplay and the nitty-gritty details of TLS (handled by libraries, not directly by Syncplay) the flow is just:

1. Server gets a valid, globally trusted certificate (for example from Let's Encrypt) - this is a prerequisite and only exception from it is using private CA which is beyond the scope here.
2. When client connects and advertises encryption support, the server sends its own public key certificate to the client (or more accurately starts whole TLS handshake dance).
3. Client performs verification procedure on that certificate using the trusted CA list (in our client implementation this happens as part of establishing encrypted connection through twisted SSL Client Endpoint. The important part here is that client needs a trusted CA list - this can be provided in several ways, for example through pycertify. Android has a built-in trusted CA list that will work with our public server certificates with broad compatibility as well as just about any certificate that you would call "publicly trusted".

I'm not sure what's the Android equivalent to establish an encrypted connection in the framework of your choice, but there definitely should be something that handles all of the black magic of TLS largely on its own.

As a side note - TLS can be very complicated, especially with regards to secure use of old versions. Syncplay uses TLS 1.3 and while technically there is still a TLS 1.2 fallback, it's completely irrelevant to using Syncplay today so feel free to ignore existence of older versions of TLS.

[Et0h]

Hi, I agree with everything @daniel-123 says but have some more information that is hopefully useful.

You appear to be using Netty 4.1 for networking. I had a quick check and https://netty.io/4.1/api/io/netty/handler/ssl/SslHandler.html provides guidance on how to implement startTLS (i.e. opportunistic TLS).

According to the guide, the client-side process on Netty is as follows:

1. Write a StartTLS request,
2. wait for the StartTLS response,
3. create a new SslHandler instance with startTls flag set to false,
4. insert the SslHandler to the ChannelPipeline, and
5. Initiate SSL handshake.

In terms of the Syncplay protocol side of things, I discuss that at yuroyami/syncplay-mobile#6

[yuroyami]

@daniel-123 How did I not think of the fact that Syncplay may not be using mutual TLS at all in the first place? Now that I actually implemented normal Opportunistic TLS (startTLS) (thanks a lot for the javadocs @Et0h, I did not even know Netty supports Op TLS out of the box), everything is working perfectly. I was able to establish a TLSv1.3 connection with the public servers. Thank you both so much for your assistance.