mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #1556] OpenSSL Version 1.0.2l on windows release #1173
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#1173
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ccoenen on GitHub (Feb 8, 2022).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1556
What happened?
On the Wayland-Support ticket (#109) I reported this issue earlier, but it's a separate issue that only clutters that thread. Currently, my barrier on windows is in version 2.4.0 (current version at time of writing) and it seems to ship with OpenSSL 1.0.2l from 2017.
on my system, there would be a more recent openssl available, this is the one on the system's

PATH:But from within barrier, the shipped 1.0.2l seems to be used:
This leads to connection problems with waynergy compiled with a more recent openssl version (and therefore no matching ciphers, apparently). The connection attempts can be seen above.
(originally from https://github.com/debauchee/barrier/issues/109#issuecomment-1016539840, and I already tried the suggestions by @joshskidmore https://github.com/debauchee/barrier/issues/109#issuecomment-1016526113 and @brmnjsh https://github.com/debauchee/barrier/issues/109#issuecomment-1030988825 )
Version
v2.4.0
Git commit hash (if applicable)
3e0d758bIf applicable, where did you install Barrier from?
BarrierSetup-2.4.0-release.exefrom this project's release page.What OSes are you seeing the problem on? (Check all that apply)
Windows
What OS versions are you using?
Windows 10, Version 21H1 Build 19043.1466)
Relevant log output
Any other information
I am trying to connect a waynergy client (linux) to the barrier server (windows)
@joshskidmore commented on GitHub (Feb 8, 2022):
@ccoenen - I apologize for the delay in replying.
I unfortunately don't have a Windows machine to test, but I would still assume your issue is either around the SSL certificate and/or options being passed to the Barrier server or Waynergy client. I may be wrong, but I don't this this is related to your Windows OpenSSL versions. Though my Barrier server is in Linux, I thought I would share my options and configurations to see if there is something strikingly obvious.
(Linux) Barrier server:
~/.barrier.conffile contains nothing related to SSL or encryption.~/.local/share/barrier/SSL/Barrier.pem. I believe this was generated by Barrier at some point.~/.local/share/barrier/SSL/Fingerprints/Local.txtfile, I have two lines. The first starts withv2:sha1:and the second starts withv2:sha256:.Waynergy client (also Linux)
~/.config/waynergy/xkb_keymap.~/.config/waynergy/tls/hash/, and automatically generated what appear to be OpenSSL SHA256 hashes of Barrier servers it connects to. I didn't do anything here; it generated these automatically.Whenever the Waynergy client attempts to the Barrier server, occasionally it does throw an SSL connection/protocol error, but ends up connecting on the next retry.
@ccoenen commented on GitHub (Feb 8, 2022):
My Barrier appears to be started with this command, according to the logfile (configured from the gui, yes the "SSL" checkbox is checked.)
The previous parameters are not working.
I now tried manually starting barrier server with parameters more closely resembling yours:
This still does not work. On my wanyergy/linux/client I get the same error as before, and the client is a little more forthcoming with info:
It should be noted that
--enable-cryptois the default now, and it's deprecated to explicitly specify.I can also offer a wireshark packet capture. My client is trying to do a TLSv1.2 handshake and offers these suites as part of the Client Hello:


The direct response to that is the server sending back the handshake-failure:
So, I tried to find which cipher suites the server would have accepted, using this script found on Stack Overflow:
So the overlap would be:
But somehow the server does not want to use them.
@ccoenen commented on GitHub (Feb 8, 2022):
interestingly,
barriers.exelogs this for any successful connection attempt by the tls test script:@ccoenen commented on GitHub (Feb 8, 2022):
I did also generate a new key/cert with the command from the wiki (slightly modified for longer validity):
Which also did not help.
@joshskidmore commented on GitHub (Feb 8, 2022):
I just tested a few things.
In full transparency, I recently switched the laptop that was using Waynergy/Sway back to Barrier/xmonad, so I'm not using this actively.
My first thought was to see if there had been Waynergy updates since I last used it, and there were. I updated to the latest release (0.0.9), ran Sway, then ran the same Waynergy command that I mentioned before. It connected without any issues other than wl-clipboard (which I had disabled after moving back to xmonad).
Now that I'm home, my second thought was to try to run a Barrier server on my Windows 10 desktop, then have this same Waynergy/Sway client attempt to connect to it. I setup Barrier as a server, enabled SSL, disabled "Require client certificate" (which I think is off by default), added a single screen for the Waynergy/Sway client, then started the daemon. On the Waynergy/Sway client, I used identical settings, except I switched the host to the IP of the Windows instance. Outside wl-clipboard issues, this worked as well. The version of Barrier I'm using on Windows is
2.4.0-release-3e0d758b/Build Date: Monday, November 1.Of note, the version of OpenSSL that Windows Barrier is reporting is also
OpenSSL 1.0.2land it's connecting using theAES256-GCM-SHA384cipher (one that you mentioned overlapped).Log from the Windows Barrier server
Note: The Waynergy/Sway desktop name is
lilbabyand the Windows 10 Barrier server hostname isDESKTOP-0FB7731/100.119.84.38.Log from the Waynergy/Sway client
Note: It was on debug verbosity, so I redacted a couple unnecessary log lines.
@joshskidmore commented on GitHub (Feb 12, 2022):
@ccoenen Were you able to get your setup working?
@ccoenen commented on GitHub (Feb 12, 2022):
No, sadly nothing really changed for me. As soon as I turn on encryption the two just won't connect with the error above.
@nonsleepr commented on GitHub (Apr 18, 2024):
Reading your comments led me to switch from Barrier to Input Leap which solved the issue for me.
While Input Leap project doesn't build their packages, the binary from Github Actions artifacts works.