Synergy-core: Connecting causes SSL23_GET_SERVER_HELLO error

[rdamazio]

After upgrading from 1.6.3 to 1.7.2 Pro, and after configuring, it won't connect, with the following error:

ERROR: secure socket error: SSL_ERROR_SSL
ERROR: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
ERROR: failed to connect secure socket

I'm using 1.7.2 on both sides, server is Linux, client is OSX 10.10.3.

It should also be noted that if it tries to use SSL but I didn't run the other binary (that gives a wizard-like interface and sets up the plugin) instead of synergyc/synergys directly, it gives me no warning that I missed that configuration step.

[legonigel]

@rdamazio I read your post, but Im still not sure what the bug is. To make this more clear, you downloaded synergy and ran the wizard on both machines?
Are you running synergy from the gui or the command line?
I just need some more info so we can try and find the bug.

[thansmann]

Saw the same issue on the client - had to update the server and that fixed it.

[parkbear01]

I got the same issue.

I ran the synergy client from gui on mac 10.10.3. and the server is running from gui on Linux Mint 17.1 Cinnamon 64-bit. Two systems are connected via LAN using a router.

I also tested the client on windows 8.1. It works fine.

Please fix ASAP. Thanks always!

[rdamazio]

In my case I'm running the Mac client from the gui and the Linux server directly (as synergys).

If it helps at all, the encryption plugin has this linkage:
$ ldd .synergy/plugins/libns.so
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fe9cd4da000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fe9cd0fe000)

[dantheman2865]

I am getting the same problem on the client. On the server side I get "new client is unresponsive."

Server is Windows 7 x64 and client is Windows 7 x86.

[kdv666]

Same problem for me. Synergy is now unusable since I "upgraded" to 1.7.2.

Server is Linux Mint 64-bit. Client Windows 7 x86.

[nbolton]

@rdamazio Does the Linux server load the ns.so plugin? I'm guessing since you're running from command line, you never ran the activation via the GUI? (This is where the plugin comes from)

[charleslouis]

hey there,

Same problem for me. I upgraded Synergy minutes ago and it now longer works.
Server : WIN7
Client: Ubuntu 14

I ran the wizrd on Windows, and did a "repair" afterwhile an used ubuntu software updater.
I use the GUI on both

Here is the log I get :

NOTE: starting client
NOTE: config file: /tmp/qt_temp.Z13575
NOTE: log level: INFO
NOTE: started client
NOTE: connecting to '192.168.1.85': 192.168.1.85:24800
ERROR: secure socket error: SSL_ERROR_SSL
ERROR: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
INFO: server connection may not be secure
NOTE: disconnected from server
NOTE: stopped client
ERROR: failed to connect secure socket

I read one could disable SSL to make it work, but I don't know how to do this.
Thanks

[kdv666]

@charleslouis

In the GUI, under the Edit menu, there is the Setting item. You can disable the SSL in there. You probably need to do it on both machines, although it was ghosted out on my linux Mint ( ubuntu-derived ) machine.

That should work for you.

Regards

[rdamazio]

I ran the GUI just to get the plugin installed, and tried starting the client through it as well, but got the same results as starting from the command line

[nbolton]

@rdamazio Ah, try --enable-crypto

[charleslouis]

Thank you @kdv666,
It didn't fix it though...

But running synergyc [server IP] on client ubuntu CLI did the trick.
Strangely enough, synergy window is not opened on Windows (server)...

I don't get it, but at least I can work :)

[speaker]

@charleslouis @rdamazio @kdv666
This issue will happen if an SSL pair are not speaking the same version of SSL or one is not speaking SSL at all. The easiest reproduction is to set the client to use SSL and disable SSL on the server. When the client gets the reply back from the server it's not an SSL reply. This triggers the protocol error.

So both server and client need --enable-crypto, and that argument (as with all args) needs to be before the network address.

If the ssl plugin is missing completely, it will act like SSL is disabled. The newest nightly builds have code to install the SSL plugin on install, and the wizard either copies or links to the plugin for each user.
The current master nightly is pretty close to what 1.7.4 will be: http://synergy-project.org/nightly?filter=099c984 although it's still in testing.

Would you be willing to take a look and see if it helps? Make sure to run the wizard to copy/link the plugins appropriately.

[charleslouis]

Thank you @speaker,
At the moment I use the CLI to run synergy from client and it works, so I won't take the risk of breaking it as I need it for work (+ my server machine is not in a good shape at the moment).
Have a nice day

[rdamazio]

Haven't tested with the flag yet, but if that's the case then consider it a request for the feature of auto-negotiating encryption (possibly with a second flag to refuse connection if SSL can't be used, for anyone who wants a higher level of security enforced), or at least providing a more useful error message.

[speaker]

That's been an internal discussion for a while now actually. This issue appears fixed by other changes, if it persists, we'll reopen it and hopefully new logging will help identify the issue better. #4793

[rdamazio]

Just tried to pass that flag to the server - still doesn't work.

On the client (OSX 10.10), I get:
SSL routines:SSL3_GET_RECORD:wrong version number

On the server (Linux), I get:
ERROR: secure socket error: SSL_ERROR_SSL
ERROR: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version

[speaker]

@rdamazio This seems to happen to other applications when one end can't handle the protocol the other end is trying to use. (with libcurl for example.) The fixes are to force SSLv3 instead of TLSv1. In our case we've actively disables SSLv3 because it's not secure. I'll look to see if there is additional logging we can use to query what protocols the SSL lib is able to use.

Using lsof() on the server, can you determine which openSSL lib is in use and what version?

[rdamazio]

$ ldd ~/.synergy/plugins/libns.so
linux-vdso.so.1 => (0x00007ffcd5bc4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd748d49000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fd748aeb000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fd74870f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd74850b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd748207000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd747ff0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd747c2b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd7491c8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd747925000)

[nbolton]

Reopening, still not fixed according to @rdamazio.

[XinyuHou]

@rdamazio
Have you tried our nightly?

http://synergy-project.org/nightly?filter=121080

NOTE: You need to rerun wizard to get the latest plugin.

[speaker]

@rdamazio Please try the new 1.7.4 nightly at http://synergy-project.org/nightly?filter=v1.7.4-stable-267f3ac and if you continue to see the issue, would you also include some logging with debug set that includes the startup sequence on the server and client? There is a lot of additional information in there now that can help us track down complicated SSL issues.

[rdamazio]

1.7.4 nightly appears to work :) Thanks!

[RobFisher]

Please can you supply links for the correct Windows and Linux nightlies to work around this bug?
Edit: I figured out the naming convention so I am going to try http://synergy-project.org/nightly?filter=cbd63e9 Edit 2: so far so good.

[stbrowne]

I think maybe there's still an issue with SSL setting checkbox not reflecting what its actually using on upgrades.

I updated today to the 1.7.4-rc8 build on my Windows Server and Mac Client and ran into this issue. I pulled up the preferences on both and they both said SSL was enabled. However, disabling SSL on my Mac client and leaving it checked on my Windows server resolved the issue even though it shouldn't have been working at that point. Then I unchecked the setting in Windows and everything still worked. Then I checked it again in Windows and its broken again. Then I checked it again in Mac and it was once again working even though according to the checkboxes this was the original configuration.

[djtooley]

Success: I had this problem then I fixed it.

I updated to 1.7.4-stable on my Win7x64 server, installed it fresh on a Win7x64 machine, and accidentally installed 1.7.4-rc8 on a Win7x32 machine, which then got updated to 1.7.4-stable.

The machines wouldn't talk, giving the error message:
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

I checked and they all had the "Use SSL encryption" box checked.

So I UNCHECKED the box on server and clients. Restarted all. Connection worked.
I then CHECKED the box on server and clients. Restarted all. And it worked!

So I speculate that the checkbox did NOT accurately reflect the status of the "Use SSL encryption" for all devices.

It works again now, so I'm happy.

[drpatso]

had this problem and I was able to resolve this.

Windows 10 64-bit running the server, plugin failed to install during install. SSL is unchecked on the server, on a windows 7 64-bit client, in synergy I had to click edit > settings > uncheck SSL. No more issue. It looks like client was trying to use SSL and the SSL plugin for some reason didn't install on the windows 10 64-bit server (it's just a regular end user version, with no antivirus or security software, not sure why plugin failed)

[DanielVF]

I had the same issue, upgrading to Synergy Pro. As @djtooley mentioned, unchecking SSL on all machines, restarting each, then checking SSL, and restarting each, fixed the problem.

[straris]

Beta version 1.8.1-beta-f7377d6
The connection error still occurs due to the SSL issue. Disabling the SSL is a workaround but I wouldn't expect a user to know that.
Server: windows 10 64bit
Client OSX 10.11 64 bit

[Surreal9]

Same experience as the previous three posters; for me OSX 10.11 64 bit client connecting to Windows 10 64 bit server. The server indicated the connection was made but client was unresponsive, and the client had the SSL error reported above. Unchecking SSL on both client and then re-enabling SSL fixed it.

[nlyan]

The SSL plugin is going away (SSL is being integrated in to core), so hopefully this problem will go away as well.

[andyneff]

Still a problem in 1.8.3-stable 64 bit
Windows and Mint 18
The "workaround" still works, but took me several attempts.

[nlyan]

Can everyone here experiencing SSL problems please try this build?

http://symless.com/nightly?filter=1.8.4-rc1-e6a3caa

[rvagg]

@nlyan no luck, running 1.8.4-rc1-e6a3caa on Linux server and OSX client, same error.

[amit-batra]

Facing same issue with 1.8.3-stable. Server is a Windows 7 x64 with SSL enabled. Client is on macOS Sierra with SSL enabled.

Steps tried:

• Rerun the configuration wizard several times on both server and client
• Restarted both server and client machines several times

Attaching a screenshot from the client.

[russell-taylor]

Same issue with Windows 10 server and Ubuntu 16.04.01 client and 1.8.3 stable. Cannot connect either with SSL turned off (the cleint claims the server refused the client with our name, the server claims the client disconnected) or with it turned on (same error now, but earlier it was complaining about SLL errors). This was a fresh install on both machines. Bad OOBE.

Trying swapping the roles of the client and server after restarting the app on both ends with SSL turned off did not help, got the same errors in the other direction.

[russell-taylor]

Installing on Windows 64 on the second machine got the same symptoms. Upon initial connection with no SLL, the client side said that it was connected and would run in the background, but then it dropped connection and kept looping. Stopping server and client and turning on SLL got the client to ask me if I wanted to accept the Fingerprint. I accepted it, and then it went back to failing and looping. On the server side, I get this log:

[2016-10-08T14:14:17] INFO: accepted secure socket
[2016-10-08T14:14:17] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
[2016-10-08T14:14:17] NOTE: accepted client connection
[2016-10-08T14:14:17] WARNING: unrecognised client name "reliasolve-3", check server config
[2016-10-08T14:14:17] NOTE: disconnecting client "reliasolve-3"
[2016-10-08T14:14:17] NOTE: client "reliasolve-3" has disconnected
[2016-10-08T14:14:19] INFO: OpenSSL 1.0.2 22 Jan 2015
[2016-10-08T14:14:19] INFO: accepted secure socket
[2016-10-08T14:14:19] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
[2016-10-08T14:14:19] NOTE: accepted client connection
[2016-10-08T14:14:19] WARNING: unrecognised client name "reliasolve-3", check server config
[2016-10-08T14:14:19] NOTE: disconnecting client "reliasolve-3"
[2016-10-08T14:14:19] NOTE: client "reliasolve-3" has disconnected
[2016-10-08T14:14:21] INFO: OpenSSL 1.0.2 22 Jan 2015
[2016-10-08T14:14:21] INFO: accepted secure socket
[2016-10-08T14:14:21] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
[2016-10-08T14:14:21] NOTE: accepted client connection
[2016-10-08T14:14:21] WARNING: unrecognised client name "reliasolve-3", check server config
[2016-10-08T14:14:21] NOTE: disconnecting client "reliasolve-3"
[2016-10-08T14:14:21] NOTE: client "reliasolve-3" has disconnected

On the client side (wish I could send my mouse over there to grab it...) it says:

[2016-10-08T14:14:21] INFO: connected to secure socket
[2016-10-08T14:14:21] INFO: server ssl certificate info: /CN=Synergy
[2016-10-08T14:14:21] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
[2016-10-08T14:14:21] ERROR: server refused client with name "reliasolve-3"
[2016-10-08T14:14:22] WARNING: failed to connect to server: server refused client with our name
[2016-10-08T14:14:23] NOTE: connecting to '192.168.0.249': 192.168.0.249:24800
[2016-10-08T14:14:23] INFO: OpenSSL 1.0.2 22 Jan 2015
[2016-10-08T14:14:23] NOTE: server fingerprint: 58:E0:1D:2F:45:97:D0:AD:F9:04:1D:58:D2:F9:19:9A:D2:A8:1B:D2
[2016-10-08T14:14:23] INFO: connected to secure socket
[2016-10-08T14:14:23] INFO: server ssl certificate info: /CN=Synergy
[2016-10-08T14:14:23] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
[2016-10-08T14:14:23] ERROR: server refused client with name "reliasolve-3"
[2016-10-08T14:14:23] INFO: service command updated
[2016-10-08T14:14:23] INFO: process started but command is empty, shutting down
[2016-10-08T14:14:24] WARNING: failed to connect to server: server refused client with our name
[2016-10-08T14:14:24] INFO: got ipc shutdown message
[2016-10-08T14:14:24] NOTE: stopped client
[2016-10-08T14:14:24] INFO: process 1712 was shutdown gracefully

[nlyan]

@russell-taylor

It looks like your Synergy server hasn't been configured to accept the client with the screen name "reliasolve-3". Can you please check your server configuration on the "screens and links" tab of the Server Configuration dialog? Hit the 'Configure Server...' button on the main window of your server. Make sure you have a screen with this name on the grid, if not drag a new one on using the right hand screen icon and name it appropriately.