[GH-ISSUE #39] SSL Error after upgrading client to 2.1.x #29

Closed
opened 2026-05-05 04:48:17 -06:00 by gitea-mirror · 8 comments
Owner

Originally created by @llitz on GitHub (May 20, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/39

Operating Systems

Server: Windows 10 - Version 1803 - Build 17134.48
Using github Binary

Client: Linux - Gentoo
Kerne:l 4.16.7
Compiling from source
INFO: OpenSSL 1.0.2o 27 Mar 2018
DEBUG1: openSSL : compiler: x86_64-pc-linux-gnu-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -march=bdver4 -O2 -pipe -mno-fma4 -mno-tbm -mno-xop -mno-lwp -madx -mrdseed -mmwaitx -msha -mxsavec -mxsaves -mclflushopt -mpopcnt -fno-strict-aliasing -Wa,--noexecstack

Barrier Version

2.1.0 Windows
2.1.x Linux (2.1.0 and 2.1.1 have same error)

When running Windows on 2.1.0 and Linux 2.0.0 error disappears

Steps to reproduce bug

Updating from 2.0.0 to 2.1.0/2.1.1 introduced the error. This is seen on client side:
NOTE: server fingerprint: xx:xx:xx:xx..............
ERROR: failed to verify server certificate fingerprint

Rolling back to 2.0.0 on client eliminates the error (without needing to change certificates or anything else. I have regenerated them but the error persists.

The server (2.1.0), sometimes, will show this error when running against the 2.1.0 client:
[2018-05-20T00:13:00] NOTE: accepted client connection
[2018-05-20T00:13:11] ERROR: ssl error occurred (system call failure)

Was anything related to SSL changed between 2.0.0 and 2.1.0?

Originally created by @llitz on GitHub (May 20, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/39 ### Operating Systems ### Server: Windows 10 - Version 1803 - Build 17134.48 **Using github Binary** Client: Linux - Gentoo Kerne:l 4.16.7 **Compiling from source** INFO: OpenSSL 1.0.2o 27 Mar 2018 DEBUG1: openSSL : compiler: x86_64-pc-linux-gnu-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -march=bdver4 -O2 -pipe -mno-fma4 -mno-tbm -mno-xop -mno-lwp -madx -mrdseed -mmwaitx -msha -mxsavec -mxsaves -mclflushopt -mpopcnt -fno-strict-aliasing -Wa,--noexecstack ### Barrier Version ### 2.1.0 Windows 2.1.x Linux (2.1.0 and 2.1.1 have same error) When running Windows on 2.1.0 and Linux 2.0.0 error disappears ### Steps to reproduce bug ### Updating from 2.0.0 to 2.1.0/2.1.1 introduced the error. This is seen on client side: NOTE: server fingerprint: xx:xx:xx:xx.............. ERROR: failed to verify server certificate fingerprint Rolling back to 2.0.0 on client eliminates the error (without needing to change certificates or anything else. I have regenerated them but the error persists. The server (2.1.0), sometimes, will show this error when running against the 2.1.0 client: [2018-05-20T00:13:00] NOTE: accepted client connection [2018-05-20T00:13:11] ERROR: ssl error occurred (system call failure) Was anything related to SSL changed between 2.0.0 and 2.1.0?
Author
Owner

@walker0643 commented on GitHub (May 20, 2018):

Hi @llitz - This issue is most likely that between 2.0 and 2.1 the data directory locations were changed to be more conformant to each platform's specs. As a result users will need to recreate their SSL certs and fingerprints (or copy the old ones). The new location for Windows is %USERPROFILE%\AppData\Local\Barrier and for Linux it's $HOME/.config/Barrier. If it's easier for you, you can simply delete the old configurations (but back them up first!) and let the Barrier UI make them as if it were a fresh install.

<!-- gh-comment-id:390505169 --> @walker0643 commented on GitHub (May 20, 2018): Hi @llitz - This issue is most likely that between 2.0 and 2.1 the data directory locations were changed to be more conformant to each platform's specs. As a result users will need to recreate their SSL certs and fingerprints (or copy the old ones). The new location for Windows is %USERPROFILE%\AppData\Local\Barrier and for Linux it's $HOME/.config/Barrier. If it's easier for you, you can simply delete the old configurations (but back them up first!) and let the Barrier UI make them as if it were a fresh install.
Author
Owner

@llitz commented on GitHub (May 20, 2018):

I have definitely done that and the Linux client didn't create anything for me under .config, I run barrier on Linux only by calling barrierc with the encryption option.

if I delete everything, 2.0 works fine, 2.1 doesn't.

I will try to move the directory and see if it works, but it should've created it automatically. Any ideas on how to track it?

<!-- gh-comment-id:390510280 --> @llitz commented on GitHub (May 20, 2018): I have definitely done that and the Linux client didn't create anything for me under .config, I run barrier on Linux only by calling barrierc with the encryption option. if I delete everything, 2.0 works fine, 2.1 doesn't. I will try to move the directory and see if it works, but it should've created it automatically. Any ideas on how to track it?
Author
Owner

@walker0643 commented on GitHub (May 20, 2018):

You need to run the UI (barrier, not barrierc) in order to approve the server's fingerprint. Either that or create a text file called TrustedServers.txt under $HOME/.config/Barrier/SSL/Fingerprints (assuming Linux) and put the server's fingerprint inside it.

<!-- gh-comment-id:390512155 --> @walker0643 commented on GitHub (May 20, 2018): You need to run the UI (barrier, not barrierc) in order to approve the server's fingerprint. Either that or create a text file called TrustedServers.txt under $HOME/.config/Barrier/SSL/Fingerprints (assuming Linux) and put the server's fingerprint inside it.
Author
Owner

@llitz commented on GitHub (May 20, 2018):

Is this a new behavior? I did not need to do it on 2.0.0? I will test in a few and report back, thanks.

<!-- gh-comment-id:390512362 --> @llitz commented on GitHub (May 20, 2018): Is this a new behavior? I did not need to do it on 2.0.0? I will test in a few and report back, thanks.
Author
Owner

@llitz commented on GitHub (May 20, 2018):

All right, so I have just tested it all starting with barrierc again (barrier doesn't show up on my server and even if it did I couldn't really click on it if I can't pass the mouse). The barrierc binary doesn't even try to read the .config/barrier/SSL/Fingerprints/TrustedServers.txt, confirmed it with strace (or any other .config/barrier or .barrier file for that matter).

The new directory tracking is outputting something wrong, I don't even know what it is trying to read and it doesn't show up with DEBUG2. Something is broken because of it.
Not sure if you can reproduce it, if not I can help track it if you point me in the right direction (I see several changes regarding the logic to find the right directory).

<!-- gh-comment-id:390517490 --> @llitz commented on GitHub (May 20, 2018): All right, so I have just tested it all starting with barrierc again (barrier doesn't show up on my server and even if it did I couldn't really click on it if I can't pass the mouse). The barrierc binary doesn't even try to read the .config/barrier/SSL/Fingerprints/TrustedServers.txt, confirmed it with strace (or any other .config/barrier or .barrier file for that matter). The new directory tracking is outputting something wrong, I don't even know what it is trying to read and it doesn't show up with DEBUG2. Something is broken because of it. Not sure if you can reproduce it, if not I can help track it if you point me in the right direction (I see several changes regarding the logic to find the right directory).
Author
Owner

@walker0643 commented on GitHub (May 21, 2018):

You're right, of course. I shouldn't have replied until I was able to verify what I was telling you, and I was remembering the linux path incorrectly. The actual path under your home directory defaults to .local/share/barrier as per the freedesktop standard. Assuming an otherwise standard installation you should have your trusted fingerprints file at /home//.local/share/barrier/SSL/Fingerprints/TrustedServers.txt.

<!-- gh-comment-id:390523506 --> @walker0643 commented on GitHub (May 21, 2018): You're right, of course. I shouldn't have replied until I was able to verify what I was telling you, and I was remembering the linux path incorrectly. The actual path under your home directory defaults to .local/share/barrier as per the freedesktop standard. Assuming an otherwise standard installation you should have your trusted fingerprints file at /home/<username>/.local/share/barrier/SSL/Fingerprints/TrustedServers.txt.
Author
Owner

@llitz commented on GitHub (May 21, 2018):

Perfect, it is working now! Thanks (=

Could I suggest some usability improvements?
1 - The fact that the fingerprint isn't found inside the TrustedServers.txt isn't completely clear on Logs. Can we add the TrustedServers.txt path to the Log?
2 - When running "barrierc --help" is it possible to indicate the --enable-crypto require servers to be listed under "$Platform_path/SSL/Fingerprints/TrustedServers.txt" and, somewhere in that help screen, provide the location for "$Platform_path".

<!-- gh-comment-id:390524950 --> @llitz commented on GitHub (May 21, 2018): Perfect, it is working now! Thanks (= Could I suggest some usability improvements? 1 - The fact that the fingerprint isn't found inside the TrustedServers.txt isn't completely clear on Logs. Can we add the TrustedServers.txt path to the Log? 2 - When running "barrierc --help" is it possible to indicate the --enable-crypto require servers to be listed under "$Platform_path/SSL/Fingerprints/TrustedServers.txt" and, somewhere in that help screen, provide the location for "$Platform_path".
Author
Owner

@darwincharle commented on GitHub (Dec 1, 2023):

Hola, buen día

hoy pase aquí porqué tengo el problema con Barrier, sucede que cuando activo el server y el client, estos no se conectan, dan error de cert SSl.

Suayuda por favor, como puedo solucionar esto?

<!-- gh-comment-id:1836331074 --> @darwincharle commented on GitHub (Dec 1, 2023): Hola, buen día hoy pase aquí porqué tengo el problema con Barrier, sucede que cuando activo el server y el client, estos no se conectan, dan error de cert SSl. Suayuda por favor, como puedo solucionar esto?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#29
No description provided.