secure server, outgoing connection rendezvous

[acrix]

make punch hole request password protected, to make server secure
currently inet accessible servers public by fact, everyone can use you bandwidth and make self private network based on you server, to make redteams ops

[paspo]

Rustdesk doesn't use password, but cryptographic key-pairs, specifically Ed25519 (elliptic curves).

It's already possible to limit the allowed clients by specifying a specific public key to be accepted.

[acrix]

this pub key easily leaked to public on external client support,
this feature request about more secure setup

[JeGr]

The pub key is irrelevant concerning security as you'd need the PRIVATE key to connect securely. Pub keys literally are to be "leaked" to the public. Don't understand where you're coming from?

[bigretromike]

The pub key is irrelevant concerning security as you'd need the PRIVATE key to connect securely. Pub keys literally are to be "leaked" to the public. Don't understand where you're coming from?

I think the issue here is that current server implementation can block any client that don't use pub_key from server, but that pub_key can be "copied" and then server can be use as someone elses relay - same issue is on vnc repeaters.

And in the end used up your bandwith for free.

@acrix If I understand your propose, you wan't to add extra password? But would it be configure on client side like pub_key ? If so how would that help ? Imo the better way to handle that would be

1. each machine can has uniq ID that is not changeable that would be send to server and on server pair-mode or whitelist machine_ID because RustDesk ID can be changed (we wouldnt' use rust ID because that could be taken out from our legit client easly (copy-paste)) ?
2. similar as 1) but using RustDesk ID which can be easly forged but still better than having it wide open.

[acrix]

@bigretromike extra password required only on outgoing connection (punch hole request) and used by admin stuff and enters by hand as any passwords :) on other side of connection (client) no extra password required, also this password required only to connect through password protected server and not used with connection thought dedicated public servers, is what i mean, to make private server widely opened on internet

[acrix]

more about 'punch hole request'

[bigretromike]

@bigretromike extra password required only on outgoing connection (punch hole request) and used by admin stuff and enters by hand as any passwords :) on other side of connection (client) no extra password required, also this password required only to connect through password protected server and not used with connection thought dedicated public servers, is what i mean, to make private server widely opened on internet

If the password wouldn't be typed on both sides, then the "machine you want to connect to" aka "client2", would have to be able to establish connection to server even without that password, which non-the-less use up server resources and (I didn't read full rendezvous protocol specialization) but would have to punch hole anyway even without that password.

So in the end the only party typing the password would be anyone wanting to connect to already connected to server client2., then again if that would be the true, then connecting as client to server would punch hole also without password.

I'm probably not seeing the full picture of that "password" thing here, and I'm lacking in rendezvous protocol know-how.

What do you think about this:

• normal rustdesk installation (on client)
• while typing server id/dns there is "connect/pair" button
• you click that and type "that password you wanted and configured on server"
• the password is used with combination with pub/priv_key and if its valid the client is added to white list on server side
• commercial version would have webui to manage all the clients etc, while free version would only be able to add/delete them by hand in sqlite style or by cli.
• In case of compromised private key, the server would be able to initializate a "Re-Pair" procedure where each client that connects with old "handshake" get ask for new "pair-password" ? that way the password would be used once. ?

while on operator side it would look similar but would use different password ? (vnc style) that way only those with success pair process would be able to use server to operate other machines ?

Dunno just throwing ideas here.

[paspo]

Another solution would be to use a CA (and a CRL) for identity management, and issue certificates for each client. Then track the association between each certificate and the client id.
So it'll be impossible to use an existing client certificate with a different client, but a newly generated client certificate can be "stolen" and associated with an "unwanted" client. If that happens, you recognize it when the "correct" client tries to connect and gets ignored; then the associated human calls you and you fix the wrong association, banning the "unwanted" client id.

This sounds like a lot of work, just for saving some bandwidth for the server.

IMHO we're better off with an allow-list of IP addresses.

[acrix]

@bigretromike

on both sides

no, only initiator and server involved
password can be set once and used only when server ask for auth on admin side

I'm probably not seeing the full picture

it not so big, actually

connect/pair
Re-Pair

this is implementation details, i think need to keep thing simple, sometimes just password good enough

@paspo

use a CA (and a CRL)

this can be optionally used, but in general "no! please! no!"

just for saving some bandwidth

sometime it can be save all bandwidth

allow-list of IP addresses

this feature request about more secure setup

[dobzhao]

I found this issue by searching, so... I agree with @acrix
I think we are talking about clients authentication, The key is used for encryption to ensure that the control data and video data are not obtained by a third party
But for enterprise usage, a problem we are facing is how to ensure that the client is properly authorized, maybe client id/ password, API key/token, JWT or LDAP/AD integration can solve the problem.

[Nopalin]

@dobzhao i like your idea, additional to the key for encryption some sort of token or uuid that the server can validate and attach it to the unique ID of rustdesk client, so even an unwanted client get these data, its rustdesk ID will be different and the server will reject that new connection. As you mention the server can implement various validation methods, and the simplest one is a password in a database, which @acrix was i think saying.

[bigretromike]

@dobzhao i like your idea, additional to the key for encryption some sort of token or uuid that the server can validate and attach it to the unique ID of rustdesk client, so even an unwanted client get these data, its rustdesk ID will be different and the server will reject that new connection. As you mention the server can implement various validation methods, and the simplest one is a password in a database, which @acrix was i think saying.

from what I see each machine has its own UUID which dont change the ID only change, but both can be easly extracted from working client.

[sbirrari]

Any advancement on this issue?

[mitsukuri]

Does the paid version solve this problem? We're setting up a small company RD server and we definitely don't want our users to spread the server ID / public key to people outside of the company, thus rendering our private server public.

[bigretromike]

Does the paid version solve this problem? We're setting up a small company RD server and we definitely don't want our users to spread the server ID / public key to people outside of the company, thus rendering our private server public.

nah.

The server need to be "public", if you want it to stay private, use VPN for each client and operate on internal network inside vpn