As HN: RustDesk Installs Chinese Root Certificates
I'm not an expert in security, but I noticed that the Windows version of RustDesk (https://rustdesk.com/), an open-source remote desktop software, installs a Chinese root certificate to the Windows `Trusted Root Certification Authorities` with all purposes enabled. There's a discussion on GitHub (https://github.com/rustdesk/rustdesk/discussions/6444) where one of the maintainers states the certificates are for driver code signing, but doesn't explain why they need to be placed in `Trusted Root Certification Authorities` with all purposes permissions instead of just for code signing. Does anyone more experienced in security have a take on this?
19 comments
[ 3.5 ms ] story [ 62.8 ms ] threadAlways be cautious of trusting certs of any kind, especially test/dev certs with top level privileges lol personally i would avoid.
Based on the issue there are too many weak points and the "response" given didnt seem to care about the vulnerabilities or user concerns, only said why its needed...
The issue poster was smart in running in a sandbox and comparing files.
"Yet another remote desktop software, written in Rust. Works out of the box, no configuration required. You have full control of your data, with no concerns about security"....
Yikes. Please don't believe in every repo face value. Your best bet is to generate your own certs (https://github.com/FiloSottile/mkcert) and sign the dlls yourself.
You should never install a root certificate from someone, unless you want them to be able to silently MITM any TLS connection from your machine.
This is something that the OS should be at some regularity reminding the user that has happened. It is not reasonable for a user to assume that installing an application is just going to let that application completely switch the trusts on the computer.
This is an unfortunate side effect of how installation works on Windows I think.
I really think we need to move closer to requesting permissions to specific things rather than a binary “admin or not”.
(When it does suffice, the approach has always been generate a CA certificate on the device itself and install that, generate a cert signed by that CA to sign the code/driver with, then nuke the CA's private keys so they can't be used to sign anything else again. There would be zero need to ever use a real CA here.)
"Frankly, as for 1,2, we do not know either, we are not expert in this field, maybe because it is test cert. As for 3, dll is OV cert, but the driversigning requires EV cert, we do not have EV cert, so we use test cert as a workaround. Someone in HN does not believe we do not have EV, but we really have not. :( But now I think it is time for us to get one."
https://i.ibb.co/bHjMYWH/2024-02-08-00h41-11.png