> RustDesk still does not support encrypted connections when self hosting
Not true at all. RustDesk connections are fully encrypted even when using a self-hosted server. What is not supported are encrypted direct endpoint-to-endpoint connections not going through a server at all, because that's not a use case RustDesk is designed for. The feature is intended for testing, which is why it's disabled altogether by default.
If your use case is focused on direct connections without a server, RustDesk is the wrong tool for the job. It's an open-source self-hostable analog to Teamviewer, the server is inherent to the design.
To establish a connection between client and remote host, you are expected to go through a coordination server which you trust, that can be either the official one or your own self-hosted instance. Your client and the remote host will then attempt to directly connect if possible, only actually sending the display and input streams through a relay server if a direct connection is impossible due to NAT or whatever else.
The use case where encryption is not supported is directly connecting by IP address, which is not the intended use for this software. It's an open source analog to TeamViewer, not a replacement for VNC or RDP. The direct connect functionality is there primarily for testing, which is why it's entirely disabled by default and the option to turn it on is buried at the bottom of a dialog that requires elevated privileges to access. If your use case is focused on those direct connections, RustDesk is not aimed at you.
I think you bring up a fine point. Most applications have encryption built in and transparent to the user. While technical IT people in charge of infrastructure will not make this assumption, it is not unreasonable, at the same time, for small business / individual users, to not understand or know of this limitation.
VNC does not, for example, and you need to set up port forwarding through ssh.
X2Go does....but I don't trust it terribly. So, RustDesk..what do you need to wrap it in? ssh?
I really want a better solution that VNC/X2Go..especially since I use hardware accelerated apps that need to use VGL to operate correctly (but underwhich operation is quite buggy).
RustDesk already encrypts connections going via Relay. Encryption is missing in direct IP to IP connections only - but you could set up an SSH tunnel, or a SOCKS or HTTPS proxy though.
Another valid alternative is Xpra, and it does support Wayland too - but doesn't reach feature parity with X11. Like RustDesk, Xpra is similarly feature-rich and mature, it too can take advantage of SSH tunnels, SOCKS or HTTPS proxies etc.
And then there's TeamViewer and AnyDesk - both of which are paid, with a free tier for evaluating or personal use - RustDesk is younger, but feature-wise they're quite similar.
Finally, you could set up wireguard that will happily encrypt your connection with very little overhead - regardless of your chosen remote desktop solution.
I disagree, modern software should make encrypted connections over something like HTTP3 or QUIC directly so true secure end to end connectivity works. This would make VPN software such as tailscale obsolete.
One of my primary use cases for tailscale/VPN is that I can happily run stuff (grafana, gitea, etc) and not have to be panicked about monitoring for CVEs - I serve it all over HTTPS but I don't want to put it on the public internet if I don't need to.
I just have envoy proxy with the oauth + jwt filter in front of those services. Envoy does the oidc flow with pocket-id so I can use passkeys for authN. Envoy validates the resulting token and does authorization via ACL. Envoy then sends an authorization bearer jwt with the oidc id_token jwt to the backend (for example grafana). Grafana parses and validates the jwt and sets claims as userinfo (username, groups, email).
I think such setups are at least as secure as having tailscale in front of it and they are web standards conform. I dont need a client app like tailscale, I can just use my normal browser and internet conn.
I always make sure envoy/all other apps are on the latest security patcb anyways.
It's funny you say that, as one of my weekend projects today is setting up https://www.authelia.com/ to achieve the same.
I probably won't allow everything through it (eg: postgres, clickhouse etc can stay on tailscale), but I've been stumbling into use cases where I want to share things with friends or colleagues, and I don't want to put them on my tailnet.
I'm also in favor of adding encrypted connections to RustDesk, not to replace tailscale, but as a part of this complete breakfast. Tailscale provides mutually authenticated, authorized L3 access. TLS can be configured to provide mutually authenticated L4 access. With a little OIDC/webauthn setup, both L3/L4 support device attestation, meaning there's no way to connect without e.g. a yubikey (or perhaps an enrolled TPM.)
Secure and censorship-resistant connectivity is very hard. We should compartmentalise and not expect everything to reimplement and maintain their own version of it and focus on specialised solutions that actually work.
What all user-facing software should have is a minimal-overhead connection option to improve performance inside user's tunnel of choice.
Pure QUIC gets blocked easily, SSH requires wrapping, even Tailscale mimicry is basic and they still ignore simple protocol improvements available.
and how do you discover the ipv6 address? memorize it? many ISPs don't listen to informational documents listing all the problems with random dynamic prefixes.
You can use either iroh directly or do it like them with dns via pkarr and use mainline DHT and ed25519 public keys that you can share via separate channels
You could just make use of public oidc/oauth2 providers like Google/Github/Microsoft/Cloudflare Generic OIDC or heck, even your bluesky account via ATProto oauth
But yeah, you could also make use of your ed25519 ssh public key as client certificate and accept based on fingerprint like ssh
"We don’t plan to implement this directly, as it is designed for test initially, we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default.
For security and privacy, we strongly advise using it in combination with a VPN—the VPN tunnel already provides end-to-end encryption, so additional encryption within RustDesk is unnecessary in that setup.
That said, we welcome community contributions!
Many users express interest or share feedback—but very few take the next step and submit a pull request.
If you’re able to help, your PR would be greatly appreciated! "
> That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you’re able to help, your PR would be greatly appreciated!
hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.
yeah it's definitely confusing messaging i can't imagine being a community contributor there and saying "ok im gonna help implement this thing that they just described as not a good fit for their thing". i think being under resourced or whatever or just not having anyone on the team that would be able to pull this off is a fine thing to be forward about, but it gets confusing because they kinda frame it like it's the wrong thing to do then leave the door open for someone else to do it. if they didn't beat around the bush perhaps they'd have encryption on this already.
I prefer when projects say "we don't have the resources for this but we agree it would be nice" because then I actually feel like it would be worth the PR. but this project makes me feel like they don't want the change which means I don't want to put in the work
> hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.
What is there to hate here, I don't understand?
They first provide a concise overview of the current situation. Then how they personally feel about it. Finally they leave it open and end it with "If you want it badly enough, we'll accept outside contributions for it".
They're not saying that they're against the feature in principle, they're saying that they themselves don't plan to spend time implementing it, but if users really want it and contribute the feature itself, they'll be happy to maintain it once merged.
This seems like the ideal solution? What would be better here?
They comment years after immediately closing the bug as wontfix, vaguely talk about users for expressing interest in features while not being willing to open a PR, when people in the thread had actually been asking, over a long period of time, whether they would accept a PR or were just opposed to the feature outright, and say they would welcome community contributions even though they think the feature is unnecessary. Then they immediately lock the issue and delete at least one comment.
I certainly interpreted the response as meaning that anyone actually trying to implement the feature would find the PR an exercise in frustration. It may be there were some cultural confusions about context and implication, but considering that they locked the issue, people weren't exactly encouraged to ask for clarification. And the developers have a sketchy enough reputation already from other incidents.
> It may be there were some cultural confusions [...] And the developers have a sketchy enough reputation already from other incidents.
Yeaah, both these points kind of makes it clear that both you and the author might have previous history with the history that goes beyond the messages that were referenced, and I don't have that context at all. I have no idea what "previous incidents" you might be referring to, so with that said I'll say that everything I've previously stated only been based on the text of that particular issue, nothing else. Based on the text from the issue alone, seems they're open to have the feature proposed as a PR to them, then if they typically reject any PRs, I have no idea about.
First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default."
Then they say you should contribute it. It's mixed messaging, it seems like they're trying to hide "won't implement this" behind "this is a bad idea in general". They should just say they won't implement it and that they're open to contributions, not that it's a bad idea and that they "strongly" recommend against it, but that maybe if someone opens a PR anyway they'll consider it.
> First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default."
Massive misunderstanding from your perspective if this is your take away. They're saying that based on the current state of the program, they don't recommend that particular approach. Nowhere in that quote of yours, does it give an indication that they don't want that feature. The only thing unambiguous from that quote, is that due to the current state of the program, they don't recommend that approach, and explains why one of the defaults is like it is.
If they didn't like the idea, or didn't want the feature, they'd say so, but they do not say that out loud, so why would you assume so?
there is another interpretation indeed, that is simply: "the Direct IP feature wasn't designed to be secure so we don't recommend using it right now, but if you contribute improvements we might accept them"
but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming? "stop asking, do it yourself" which I hate just as much as hiding your real response behind recommendations.
> but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming?
That's is a statement of truth though? "Many ask, none provide, you want it, you contribute it" seems to be the vibe, which is completely understandable and also expected in FOSS. It's not hostile or shaming for the sake of shaming.
Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario?
I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?
> That's is a statement of truth though? "Many ask, none provide, you want it, you contribute it" seems to be the vibe, which is completely understandable and also expected in FOSS. It's not hostile or shaming for the sake of shaming.
I understand a lot of projects take this attitude but that doesn't mean it's always deserved.
> Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario?
I think it's upsetting here. Not "bad", not even necessarily inappropriate or disproportionate but upsetting. Not because I wanted them to do the work for me but because I would have wanted to feel actually welcome to do the work myself instead of made to feel like it would be a further annoyance.
This kind of attitude from the project genuinely makes it feel like if I opened a PR, it would sit and rot just like the many issues have. It does not make me feel like they are actually interested in the problem or empathize with their users whatsoever, so what motivation would they have to accept the work even if it was done for them?
> I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?
Did you not see the example I already posted elsewhere in the thread? Here it is again: I prefer when projects say "we don't have the resources for this but we agree it would be nice"
Here, they aren't agreeing with it whatsoever, they just say they don't have it and that they don't recommend using the related features and that they won't consider it without a pull request. That's basically "we don't have this, won't build this and won't consider user requests" and it has absolutely nothing positive for the people who would build such a PR.
As much as they technically don't need such things because they're perfectly clear and if you don't like it you can suck it up or fork or quit computing to go live on a farm, do you not see how their response could have been better? They could be encouraging people to submit PRs but instead they're shaming people for not doing it. That response would only be deserved towards people who genuinely have expressed that they want it for free, but nobody has expressed this and yet they are still taking this attitude. It's disappointing and does not foster a culture of genuine contribution, just a culture of "stop being entitled"
Yeah, that's the core difference in our readings I think, the mere fact that they say openly they welcome someone contributing the feature, does mean they agree with it, why offer to accept such a contribution otherwise? Are they lying/not being honest, and the PR would just sit there without being accepted.
It's clear you think so, and it does feel like you have past experience with the project so I guess that is what it is. I don't have your past experience, so I don't know, but hits me as strange to ask for contributions for a feature you don't actually want, I don't understand why'd they do that.
> They could be encouraging people to submit PRs
The text I read, gave me the impression they are encouraging people to submit PRs, but maybe there is something between the lines I'm missed when I read it.
They say they welcome contributions in general and that users generally don't submit PRs to go with their feature requests. They don't say they will accept a PR for the specific feature or that they want one. As much as it may seem obvious, it's technically not what they said.
> It's clear you think so, and it does feel like you have past experience with the project so I guess that is what it is. I don't have your past experience, so I don't know, but hits me as strange to ask for contributions for a feature you don't actually want, I don't understand why'd they do that.
I was a member of a discussion I linked in another comment about password complexity requirements, but I do not have experience with raising other issues or trying to get features accepted, so none of this is a simple grudge, just a very pedantic reading of their response.
I do have experience with manipulators that use exactly this kind of language to make good implications that they don't actually intend to honor. (Including myself at points.) So maybe my reading is unnecessarily pessimistic, but it's not based on some prior experience with them, just the particular way they made their statement.
> They don't say they will accept a PR for the specific feature
Again, to me it's 100% clear they would accept a PR, but I guess there is nuance in "we welcome community contributions" and "your PR would be greatly appreciated"...
Also again, obviously you've already made up your mind. But as the perspective of someone who never interacted with the project, the impression (based on their words) is that they'd like a PR for this feature.
Besides "they don't intend to honor it!1!" which is essentially a guess, do you have any previous cases where they actually explicitly said they'd accept a contribution and then they dragged their feet accepting it/rejected it?
I think we should agree to disagree here -- I read their comment and it says they generally accept contributions, but nothing about the specific contribution. You read their comment and it looks perfectly clear to you that they're looking to accept the specific contribution.
Your statement is not entirely accurate. This only applies when using Direct IP Access on local networks, which is off by default. Their justification and invitation to PRs is the final comment [1] on the issue you linked. Why are you leaving this information out of your comment?
>RustDesk is a single open-source application (AGPL) with its own architecture. Clients connect outward to an ID/rendezvous server, which brokers a peer-to-peer or relayed session. Per the RustDesk documentation, traffic is end-to-end encrypted (built on NaCl)
Not yet...good to chastise me on this, but in my defense, I am at work, and am just trying to get a sense of this, as I would like to move away from VNC.
The specific purpose of RustDesk is to have the middleman making remote access across networks easier. It's intended to replace TeamViewer, LogMeIn, etc. not VNC or RDP.
You either pick a middleman you want to trust or you run one of your own, if you don't want that or need the features if offers RustDesk is not for you.
