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.)

So I'm supposed to set up PKI before I can open a remote console connection?

Please just make it work seamlessly with my existing SSH credentials. Like SFTP.

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

You don't need PKI.

Nothing prevents RustDesk from implementing TLS TOFU (see e.g. Gemini Protocol), which offers the same security guarantees as SSH TOFU.

agreed, zero-trust solution with proper endpoint security and PKI is superior to transport encryption and insecure protocols

so without tailscale or any other intermediary turn service how does my computer behind a NAT connect to another computer behind another NAT

Ideally using ipv6 without NAT, but yeah hole punching or quic address discovery like iroh does works too

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.

Dynamic DNS is fine for many use-cases.

I suppose, but then everybody else knows your IP too, which nullifies one of the benefits of IPv6.

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

https://app.pkarr.org/

https://www.iroh.computer/blog/v1

by using something like iroh.

basically an embedded tailscale.

but it just moves the dependency from tailscale's relay servers to iroh's relay servers. Says it right there in your article:

> The public relays we run have seen more than 200 million endpoints created, in the last 30 days alone

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.

You can use the great oauth2-proxy as a forward auth proxy to archive that if you use nginx btw, i did that before envoy.

Tailscale also protects against login attempts.

managing the certificates safely is too much of a hassle. especially if i dont want to accessible on public internet.

Doesn't Iroh do that? It would be great to go back to the peer to peer days, but with security.

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.