Et0h
commented
2 years ago Syncplay uses Opportunistic TLS.
In my understanding the way it works from the Syncplay client's perspective is as follows:
- Syncplay client connects to the server and sends the message
{"TLS": {"startTLS": "send"}}using plaintext. - If TLS is supported then server responds with
{"TLS": {"startTLS": "true"}}using plaintext. - Once the
{"TLS": {"startTLS": "true"}}message is received by the client, the Syncplay client will actually try start the TLS connection. The client will wait until the connection is established before proceeding with the 'hello' messages which is sent over the upgraded connection. Subsequent messages will also be encrypted. - Otherwise server responds
{"TLS": {"startTLS": "false"}}in plaintext and Syncplay just tells the user that TLS is not supported and sends the hello messages and subsequent messages in plaintext. - If the Syncplay server is 1.6.3 or below then it would respond with an error message when it gets the starTLS message and terminate the connection. In this case, Syncplay client reconnects and skips asking if the server supports TLS and just sends the hello message and subsequent messages in plaintext. Syncplay 1.6.4 with TLS support was released in June 2019 so you might not need to handle this edge case, but that's the expected behaviour for the Syncplay client.
yuroyami
The TLS (Transport Layer Security) connection is not getting established. As a consequence, Syncplay now connects to the servers via a bare unprotected TCP/IP socket.
For many people, this is neither a priority nor an issue. But most of us prefer a secured connection over TLS/SSL if possible, which is one of the major features for Desktop's Syncplay.
This will be fixed asap.