[GH-ISSUE #1204] Client authentication: what prevents a rogue client from connecting to a server and stealing the clipboard? #972

New issue

Open

opened 2026-05-05 07:20:32 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 07:20:32 -06:00

Owner

Originally created by @jleproust on GitHub (Jun 21, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1204

Hello,

(I have searched the issues and wiki about this topic but found nothing, sorry if I missed something.)

I understand the server authentication using a certificate and private key, and checking the server fingerprint on the client, preventing man-in-the-middle attacks and stealing keystrokes.

But what prevents a rogue client from connecting to a server in the place of a known client? Obviously the user would find the connection to the legit client broken, but the rogue client could leave and let the legit one reconnect, and all the user could experience would be a slight lag when switching desktops. Meanwhile, the rogue client would have had the time to steal the server's clipboard content, leading a potentially serious confidentiality issue, if the clipboard contained data from a password manager for example.

What do you think? I have no proof of concept, but just launching the client from a rogue host on the same network would work the same as the legit client. I guess client certificates with trusted fingerprints on the server could mitigate this risk, and disabling clipboard-sharing works too obviously, but some other data that I don't know about may be at risk.

Originally created by @jleproust on GitHub (Jun 21, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1204 Hello, (I have searched the issues and wiki about this topic but found nothing, sorry if I missed something.) I understand the server authentication using a certificate and private key, and checking the server fingerprint on the client, preventing man-in-the-middle attacks and stealing keystrokes. But what prevents a rogue client from connecting to a server in the place of a known client? Obviously the user would find the connection to the legit client broken, but the rogue client could leave and let the legit one reconnect, and all the user could experience would be a slight lag when switching desktops. Meanwhile, the rogue client would have had the time to steal the server's clipboard content, leading a potentially serious confidentiality issue, if the clipboard contained data from a password manager for example. What do you think? I have no proof of concept, but just launching the client from a rogue host on the same network would work the same as the legit client. I guess client certificates with trusted fingerprints on the server could mitigate this risk, and disabling clipboard-sharing works too obviously, but some other data that I don't know about may be at risk.

gitea-mirror commented

2026-05-05 07:20:35 -06:00

Author

Owner

@furkanmustafa commented on GitHub (Jul 6, 2021):

This is very far from being paranoid. An extremely minimal security expection.

I guess client certificates with trusted fingerprints on the server could mitigate this risk, and disabling clipboard-sharing works too obviously, but some other data that I don't know about may be at risk.

Server side confirmation of clients should suffice. A dialog like below.

"A client (machine-name.local, 12.34.56.78) with fingerprint AA:BB:CC... is trying to connect. Allow?"
Options, "Allow once", "Always allow", "Deny/Block"

A preconfigured list of trusted key fingerprints in config file could also be a convinient option.

@furkanmustafa commented on GitHub (Jul 6, 2021): This is very far from being paranoid. An extremely minimal security expection. > I guess client certificates with trusted fingerprints on the server could mitigate this risk, and disabling clipboard-sharing works too obviously, but some other data that I don't know about may be at risk. Server side confirmation of clients should suffice. A dialog like below. * "A client (machine-name.local, 12.34.56.78) with fingerprint AA:BB:CC... is trying to connect. Allow?" * Options, "Allow once", "Always allow", "Deny/Block" A preconfigured list of trusted key fingerprints in config file could also be a convinient option.

gitea-mirror commented

2026-05-05 07:20:36 -06:00

Author

Owner

@lieryan commented on GitHub (Jul 9, 2021):

if you are so paranoid you could setup a rule in your firewall, allowing only specific ips to access.

That wouldn't really solve anything. I think the attack scenario here is users that the attackers are connected to the same network. This may be because you set up barrier server in a laptop and you brought this laptop to a coffee shop/hotel with public Wifi or to connect to work network, a rogue co-worker could steal keyboard inputs there if you don't shutdown the barrier server.

Additionally, in these scenarios, your laptop are usually going to be connected using dynamically allocated IP address, so you can't just whitelist an IP address in your firewall.

A proper security here can be achieved by using two-way/mutual authentication between client and server. If the server also has to approve the connected client's TLS fingerprint, then that would eliminate those attack scenarios above.

@lieryan commented on GitHub (Jul 9, 2021): > if you are so paranoid you could setup a rule in your firewall, allowing only specific ips to access. That wouldn't really solve anything. I think the attack scenario here is users that the attackers are connected to the same network. This may be because you set up barrier server in a laptop and you brought this laptop to a coffee shop/hotel with public Wifi or to connect to work network, a rogue co-worker could steal keyboard inputs there if you don't shutdown the barrier server. Additionally, in these scenarios, your laptop are usually going to be connected using dynamically allocated IP address, so you can't just whitelist an IP address in your firewall. A proper security here can be achieved by using two-way/mutual authentication between client and server. If the server also has to approve the connected client's TLS fingerprint, then that would eliminate those attack scenarios above.

gitea-mirror commented

2026-05-05 07:20:37 -06:00

Author

Owner

@alectrocute commented on GitHub (Jul 30, 2021):

Then again i sometimes don't lock my car door when going shopping so you could call me careless...

I used to be this way. Used to be.

@alectrocute commented on GitHub (Jul 30, 2021): > Then again i sometimes don't lock my car door when going shopping so you could call me careless... I used to be this way. Used to be.