Daniel Garcia

auto config service ssl certificate broken (also, your customer support form)

16 posts in this topic

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.

Share this post


Link to post
Share on other sites
14 hours ago, Daniel Garcia said:

My suspicion is that your SSL certificate is broken

Could you try again? It was self-signed (not a security issue) but now it's 3rd party signed.

Share this post


Link to post
Share on other sites

Self signed, in and of itself isn't a security issue - but there's absolutely no trust behind it - which is why browsers/libraries have slowly stopped trusting self signed certs by default.

However, that also doesn't seem to have fixed the errors:

https://synergy-logs.symless.com/f1a580f90b38117d6a08effc2ee608c0/logs/67-2018-01-04T01-32-20.log

[ Service ] [2018-01-04T01:30:31] debug: retrying cloud connection
[ Service ] [2018-01-04T01:30:31] debug: retrying websocket connection now
[ Service ] [2018-01-04T01:30:31] debug: connecting websocket: pubsub1.cloud.symless.com:443
[ Service ] [2018-01-04T01:30:32] error: websocket handshake error 3: WebSocket upgrade handshake failed
[ Service ] [2018-01-04T01:30:32] error: websocket handshake response 400: Bad Request
[ Service ] [2018-01-04T01:30:32] debug: clearing last profile snapshot
[ Service ] [2018-01-04T01:30:32] debug: retrying websocket connection in 23s
[ Config  ] [2018-01-04T01:30:32] debug: service cloud connection error
[ Service ] [2018-01-04T01:30:32] debug: retrying cloud connection
[ Service ] [2018-01-04T01:30:32] debug: retrying websocket connection now
[ Service ] [2018-01-04T01:30:32] debug: connecting websocket: pubsub1.cloud.symless.com:443
[ Service ] [2018-01-04T01:30:33] error: websocket handshake error 3: WebSocket upgrade handshake failed
[ Service ] [2018-01-04T01:30:33] error: websocket handshake response 400: Bad Request
[ Service ] [2018-01-04T01:30:33] debug: clearing last profile snapshot
[ Service ] [2018-01-04T01:30:33] debug: retrying websocket connection in 17s
[ Config  ] [2018-01-04T01:30:33] debug: service cloud connection error
[ Service ] [2018-01-04T01:30:33] debug: retrying cloud connection
[ Service ] [2018-01-04T01:30:33] debug: retrying websocket connection now
[ Service ] [2018-01-04T01:30:33] debug: connecting websocket: pubsub1.cloud.symless.com:443
[ Service ] [2018-01-04T01:30:33] error: websocket handshake error 3: WebSocket upgrade handshake failed
[ Service ] [2018-01-04T01:30:33] error: websocket handshake response 400: Bad Request
[ Service ] [2018-01-04T01:30:33] debug: clearing last profile snapshot
[ Service ] [2018-01-04T01:30:33] debug: retrying websocket connection in 15s
[ Config  ] [2018-01-04T01:30:33] debug: service cloud connection error
[ Config  ] [2018-01-04T01:30:35] info: Sending log file...

Also the support form on https://symless.com/contact/customer-support is still broken and won't actually upload.

Share this post


Link to post
Share on other sites

Also the form offers a twirl-down that self-populates the ID data for logs uploaded. Really clever idea. However, it only does so for 2 logs. 

Also, one can click to add more computers to the form but this feature is useless since the log ID will not auto-populate nor can it be manually entered. 

 

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Daniel Garcia said:

Also the support form on https://symless.com/contact/customer-support is still broken and won't actually upload.

We can't reproduce the problem. Could you share a screenshot or a screen recording?

Share this post


Link to post
Share on other sites

There’s nothing to show in a screen recording, I hit the “submit request” button and nothing happens - this is with Safari on High Sierra and Chrome on there as well (I forget the specific version of chrome - but I have it setup to auto update - so most recent). 

Share this post


Link to post
Share on other sites
3 hours ago, Daniel Garcia said:

There’s nothing to show in a screen recording, I hit the “submit request” button and nothing happens - this is with Safari on High Sierra and Chrome on there as well (I forget the specific version of chrome - but I have it setup to auto update - so most recent). 

Got it. Can you open the developer console in your browser? If so, do you see any errors?

Share this post


Link to post
Share on other sites

I too am experiencing all these errors. :(

Customer support page error

Uncaught TypeError: Cannot read property 'log_url' of undefined
    at resolveLogID (customer-support:854)
    at HTMLDivElement.<anonymous> (customer-support:491)
    at Function.each (symless-ae01541f17.js:1)
    at mt.fn.init.each (symless-ae01541f17.js:1)
    at HTMLAnchorElement.<anonymous> (customer-support:482)
    at HTMLAnchorElement.dispatch (symless-ae01541f17.js:2)
    at HTMLAnchorElement.g.handle (symless-ae01541f17.js:2)
    at HTMLAnchorElement.nrWrapper (customer-support:13)

And my synergy log since I cant post it through support page: https://synergy-logs.symless.com/1ea6ce209aa8b938646152569a9b4c6b/logs/15-2018-01-04T16-19-04.log

I get "There was a problem connecting to the auto-config service." error when opening the Synergy application on macOS. Everything is working just fine on my Ubuntu machine.

Share this post


Link to post
Share on other sites

After a quick debug of support page...

// from customer-support.js

var supportLogs = [];

getSupportLogInfoByID("my form entered log URL") {
 for (var i = 0; i < supportLogs.length; i++) {
   // This loop never runs as values are never added to supportLogs
   // its initialized empty, and this loop is the only time its
   // every used again.
 }
}

 

Share this post


Link to post
Share on other sites

[Error] TypeError: undefined is not an object (evaluating 'supportLog.log_url')
    nrWrapper (customer-support:13:11821)

is what's popping up in my console - and yeah, supportLogs is never initialized, which means that getSupportLogInfoByID will return nil which will  cause resolveLogID to error out - so, the same thing that Jared is seeing.

Share this post


Link to post
Share on other sites

Getting the same problem with "400: Bad Request" from the synergy-service when connecting from Linux. I was able to get it to run on OSX after clicking "Retry" when I got the error about connecting to the auto-config service.

[ Service ] [2018-01-05T12:13:38] debug: retrying websocket connection now
[ Service ] [2018-01-05T12:13:38] debug: connecting websocket: pubsub1.cloud.symless.com:443
[ Service ] [2018-01-05T12:13:38] error: websocket handshake error 3: WebSocket upgrade handshake failed
[ Service ] [2018-01-05T12:13:38] error: websocket handshake response 400: Bad Request
[ Service ] [2018-01-05T12:13:38] debug: clearing last profile snapshot
[ Service ] [2018-01-05T12:13:38] debug: retrying websocket connection in 29s

 

Share this post


Link to post
Share on other sites

@Daniel Garcia  Just to elaborate on the SSL certificate issue. The reason why our websocket/pubsub server was using a self-signed certificate is that this server is never intended nor required to be accessed through the users browser, or by third-party applications or services.

Enabling the full operating system default certificate store in many scenarios actually reduces security. It tends to be trivial for nosy network administrators, who want to monitor everything their users are doing, to install MITM friendly root certificates as a matter of network-wide policy. I personally don't consider it desirable to make this easy in non-Enterprise products.

It is also fairly common for malicious or just plain-sloppy software to install root certificates in to the OS's certificate store. You can read about a particularly notorious example of this here  https://en.wikipedia.org/wiki/Superfish#Lenovo_security_incident

The reason the subject name (which was previously our servers IP address) on the certificate was incorrect is that the server was upgraded, which resulted in an IP change, and the old certificate was simply reused. Not regenerating the certificate was an oversight.

The API endpoint server, which is what you hit when you use our one-click login button, has always been signed by a trusted CA.

We understand that it can be unnerving to see connections to our servers when using a partially closed-source product that captures your keystrokes, so I hope this puts your mind at ease

Share this post


Link to post
Share on other sites
On 5/1/2018 at 8:52 PM, Andrew Nelless said:

The API endpoint server, which is what you hit when you use our one-click login button, has always been signed by a trusted CA.

 
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:
  1. Install Charles (or Fiddler) on a monitoring machine.
  2. Install the charles (or Fiddler) root certificate on the Synergy machine.
  3. Set up Charles (or Fiddler) as http and https proxy on the Synergy machine.
  4. 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.

Share this post


Link to post
Share on other sites

Short update: instead of the Comodo multi-domain certificate, I now see a LetsEncrypt certificate. Which has advantages and disadvantages for the whole issue ;)

Share this post


Link to post
Share on other sites
On 10/01/2018 at 8:16 AM, Patrick Kolla-ten Venne said:

and then track all clipboard content shared between screens, including all those passwords Synergy users might share between desktops.

Keyboard, mouse and clipboard data is not shared over the internet. An attack would only be possible if you were on the same LAN. However, if someone can install root certificates on your computer, you probably have bigger problems.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.