rustdesk / rustdesk-server

Describe the bug

I noticed that connections between two RustDesk clients are unencrypted when the key files of the server have a trailing line break, even when the server has been set up to allow encrypted connections only. I can reliably reproduce this.

Describe the environment

I've set up the S6-Overlay image using docker compose. In the environment section I have "ENCRYPTED_ONLY=1" set, as suggested in the documentation. The version of RustDesk server is 1.1.9 (latest).

How to Reproduce the bug

I generated a key pair using

docker run --rm --entrypoint /usr/bin/rustdesk-utils rustdesk/rustdesk-server-s6:latest genkeypair

and copy pasted the output into two separate key files. These files are stored as secrets as described in the documentation. The string in the file ends with a trailing new line.

Expected behavior

RustDesk should only allow encrypted connections between clients. When a client does have no or a wrong key in the settings, it should display a key mismatch error.

Actual behavior

When I connect two machines to the server, I am able to initiate a connection between them using the RustDesk client, but the icon in the top right corner shows a direct, unencrypted connection. What I find interesting here is that the RustDesk server logs that the key pair is valid on startup and when I open a shell inside the container using docker exec, I can see that the ENCRYPTED_ONLY environment variable is correctly set to 1. Furthermore, when I run top inside the container, I can see that both hbbr and hbbs have been started with the -k _ argument, which (as far as I know) should only allow encrypted connections. The key that is set in the RustDesk client seems to be completely ignored in this case. It does not make a difference whether I set the correct key, a random string or no key at all. I always get an unencrypted connection. When I remove the trailing line break from the key files, recreate the container using docker compose down and docker compose up and establish a connection between the two clients again, the icon in the top right corner shows an encrypted connection. In the latter case, setting a wrong key in the clients network settings does give me a key mismatch error, as I would expect.

Inside the running container you have a /data directory, which should contain the public and private keys, generated from secrets, from the environment or just mapped.

From my test, if you provide a private key with a trailing line feed, this somewhat invalidates the key.

IMHO it's ok if hbbs doesn't work as expected if you provide an invalid key, but you should probably get an error.

The key is read in this function:

rustdesk-server/src/common.rs

Line 108 in 0ebfc09

pub fn gen_sk(wait: u64) -> (String, Option<sign::SecretKey>) {

The file contents are then base64 decoded and the resulting data is checked for length, it must match sign::SECRETKEYBYTES (the expected length of the secret key).
If the length matches, the public key is derived from the secret key.
Otherwise, an empty private key is returned, and that leads to this behavior.

@rustdesk maybe it's better to raise an error if the size of the secret key is incorrect?

maybe it's better to raise an error if the size of the secret key is incorrect?

Yes

#348

Encrypted only RustDesk server allows unencrypted connection when key files have a tailing line break