First off, trying both Chrome and Safari on High Sierra - your customer support form at https://symless.com/contact/customer-support does _not_ upload. Something about your attempts at validating form fields seems to be erroring out, blocking uploading the form. Here's the log files:
https://synergy-logs.symless.com/f1a580f90b38117d6a08effc2ee608c0/logs/67-2018-01-03T09-34-20.log and https://synergy-logs.symless.com/f1a580f90b38117d6a08effc2ee608c0/logs/67-2018-01-03T09-57-36.log
My suspicion is that your SSL certificate is broken, and folks running recent OS versions have SSL libraries that refuse to validate connections to sites that a) use a self signed certificate and/or b) have an ssl certificate that does _not_ match the hostname being connected to - see https://www.sslshopper.com/ssl-checker.html#hostname=pubsub1.cloud.symless.com - it's 2017, with services out there like Let's Encrypt, who self signs a public facing web service anymore? (And, for that matter, gets the hostname on the self signed certificate wrong?)
When I saw that Synergy 2 had come out of Beta, I had high hopes for being able to start using it again.
I'm glad that you admit that it's fairly common for malware to install fake root certificates. I guess you would not doubt either that DNS hijacks are even more common (the cheapest one require a simple change to the hosts file).
I've verified that Synergy requires a trusted certificate from the API endpoint server, but it's actually taking any trusted certificate, and even the trusted certificate is extremely weak.
This means Synergy can be attacked using fairly common methods. A man-in-the-middle attack can be performed on v1.api.cloud.symless.com using a dns hijack and a locally installed root certificate. The attacker could, to sum it up in simple terms, insert a small 0 or 1 pixel wide screen between the users main screens by manipulating or inserting /profile/update and /screen/update calls, and then track all clipboard content shared between screens, including all those passwords Synergy users might share between desktops.
Usually installing a DNS hijack and a custom root certificate needs elevated admin / root privileges, but there are possible other approaches. DNS hijacks can be (and are) performed using DHCP hijacks (there's some malware doing exactly that), and since the trusted certificate you use is a common Comodo certificate where symless is just one of dozens of alternate names, hacking any of the other alternate servers (some of which run outdated and vulnerable software) would allow an attacker to use exactly the same original certificate.
This means that to avoid possible attacks, you would not only need to implement certificate pinning, but also use a dedicated trusted certificate instead of that cheap one for the masses. The Synergy machines can be as safe as a machine can be, without those two fixes, they're vulnerable even without a single piece of malware reaching them.
Don't believe it? Here are some easy steps to see:
Install Charles (or Fiddler) on a monitoring machine.
Install the charles (or Fiddler) root certificate on the Synergy machine.
Set up Charles (or Fiddler) as http and https proxy on the Synergy machine.
Watch how Charles (or Fiddler) decrypts the https traffic on the monitoring machine.
Now imagine that instead of the software above that simply monitors, another software intercepts and manipulates the traffic, either as a proxy, or through a redirection.
As a side note: I informed Symless about this more than six weeks ago to make this a reasonable disclosure. The efforts to fix this would have been a few hundred dollars for a trusted dedicated certificate, an hour for an administration to set this certificate up (including time for coffee and cookies), and a few lines of code for the certificate pinning, maybe a few more lines to make an exception for the software update queries.