Information about our TLS/SSL implementation and common issues.
Synergy 1 uses up to TLS 1.2 via the OpenSSL v1.0.2o library. TLS is often referred to as SSL for legacy and user-experience reasons, but as TLS is actually the successor of SSL, the two are different. It is important to use TLS because it is more secure than SSL. If you do not enable SSL/TLS in Synergy 1, a malicious user with local network access can view your keystrokes. We plan to have TLS as standard in Synergy 2 (currently in beta).
If using Windows, we guarantee TLS 1.2 because the library is distributed with our app, and an up to date macOS install should have TLS 1.2 available, but on Linux this depends what version of OpenSSL you have installed (we recommend that you install the latest Linux security updates). We have plans to adopt TLS 1.3 when it's released to provide our users with the maximum level of protection (this version is currently an IETF draft and is not yet available).
Applications that do not use TLS for network encryption do provide strong protection against an attacker with access to your network (fairly achievable if you have a WiFi network), and these programs should not be used in an environment where sensitive data is transferred over the network. Roll-your-own, self-implemented cryptography should be avoided at all costs, as we learned in 2013 and later fixed (AES encryption alone is not enough, so we implemented SSL initially and later upgraded to TLS). If a network application does not explicitly say that TLS is used, we recommend you avoid it.
The server generates a new self-signed certificate which is unique for each install. On connecting to the server, the user is prompted with a fingerprint dialog on the client, asking them if they trust the server (similar to how SSH works).
In 2015, we implemented SSL_OP_NO_SSLv3 which protects users against the Heartbleed Bug and other vulnerabilities. We still use the legacy SSL function which makes use of TLS 1.2 if it's available, falling back to TLS 1.1 or 1.0, but not SSL which is disabled (we plan to force TLS 1.2 soon depending on impact to users).
When TLS/SSL is turned on in your settings, absolutely everything sent over the network is encrypted; keystrokes, mouse data, clipboard, files, etc. If a client does not have TLS/SSL enabled, then it will not be able to establish a connection with a server that has TLS/SSL.
There is a known bug where sometimes the self-signed .pem certificate is not generated, in this case TLS will not work. An SSL error message is usually caused by this bug, and there's a workaround. On the server, disable and re-enable SSL/TLS in your settings.