You can search the forum using the search field on the blue bar above:
I have some security related remarks/requests of which I am not really sure that they have been asked before (the forum doesn't have a search function).
This is a good point. We'll add a message in one of the subsequent updates.
Blocking the connection is ok from a security point of view, but I would like to have a message saying something like: "Connection aborted, because host doesn't have the pre-shared secret"..
I'm not sure this is possible but I will forward this question to our developers nonetheless.
I wonder if it would be possible to have the RU Server (service) running under a restricted account instead of the System account.
For now - yes, it is possible. But it cannot lead to any breach or security problems by definition. The Host can only grant access, it cannot "get access".
As far as I can see now it is possible for unknown hosts to join my (public accessible) RU Server.
This won't solve the problem. The problem of unwanted Hosts connecting to RU Server originates from the fact that an admin/tech shares their Host package - e.g. puts it on a website for everyone to download as part of a support service. Any settings that you put in the Host then will be cloned on whichever machine it is run.
If you would work with pre-shared secrets for hosts and server, RU Server could block incoming connections that do not have the pre-shared secret.
A shared secret is not a means or another tier of authorization. It is a means of confirming the identity of the Host. That is, making sure that the Host wasn't replaced with another Host with the purpose of harvesting your password.
If the host has a pre-shared configured and the viewer doesn't, the viewer still can access the host. While this might be useful in some cases, I would like to have the option in the host settings to deny the connection when a viewer doesn't have the pre-shared secret.
Exactly. That was the reason why we implemented such identification.
I think having a certificate check is more in line with the current standard in identification so that is good news.
Nothing is required on the user part. The certificate is generated automatically, you cannot "disable" it. I.e. this system is always on - the user will only know that something is wrong when the Viewer cannot check the validity of the certificate.
On the other hand, it might make things a little bit more complex for the average user. But of course a lot of stuff can be automated (e.g. generating and signing certificates).
You pinned it down :) The server is designed to work with full privileges.
Of course the service must be designed to work under a restricted account, if not then I agree with you that it is a half-baked solution and you might run into problems sooner or later.
Thank you! We will definitely take note.
But I want to stress that having a service running under a restricted account is really an additional security layer and is not something to be taken lightly. Especially when this service is accessible from the outside. Improving security is done by adding robust and tough layers on different levels in the system. I really hope you take this in consideration and have a look at this topic.
* Website time zone: America/New_York (UTC -4)