Conrad Sallian's community posts

Hello Matthew,

Thank you for your post.

Have you checked this one https://www.remoteutilities.com/support/docs/internet-id-connection-not-working/ ?

Hello Tony,

We will be reviewing and updating the mobile app some time soon and we'll look at this issue too. Sorry for any inconvenience.

Could you tell us the phone make/model and Android version? Thanks.

You are welcome! And thank you for the kind words!

Hello Tony,

Thank you for your post.

You should double-tap and start holding on the second tap. That way it should work.

Hello Jim,

We are still working on it. The updated mobile should become available either at the same time, or a little bit later than the Viewer for Mac (which is our current priority).

Hello,

I think having a certificate check is more in line with the current standard in identification so that is good news.

Exactly. That was the reason why we implemented such identification.

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

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.

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.

You pinned it down :) The server is designed to work with full privileges.

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.

Thank you! We will definitely take note.

Don't hesitate to ask me if you have other questions.

Hello,

Update on this subject.

We are planning to remove the shared secret mechanism altogether in the next update. Instead, there'll be a certificate check and a warning if the Viewer cannot verify the certificate of the Host.

Next, about whether the server can work under a user account. In theory, this might be possible, but this will  inevitably cause problems whenever the server needs to perform actions that require administrative privileges. Software like RU Server is supposed to run with full privileges. It is much better to devote time and resources to protect the server and the network in the first place, rather than resort to half-baked (and ineffective) solutions such as preventing programs from running with admin privileges when they are supposed to run with them.

Hello,

Thank you for your post.

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

You can search the forum using the search field on the blue bar above:

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

This is a good point. We'll add a message in one of the subsequent updates.

I wonder if it would be possible to have the RU Server (service) running under a restricted account instead of the System account.

I'm not sure this is possible but I will forward this question to our developers nonetheless.

As far as I can see now it is possible for unknown hosts to join my (public accessible) RU Server.

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

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.

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.

Still, we'll give more thought to how we can ensure no unwanted Hosts can connect to the server. A unique PIN or (as you suggested) a shared secret can work but only in some cases. It's  not a 100% solution, unfortunately.

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.

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.

Therefore, if the corresponding connection in the Viewer doesn't have the shared secret field populated the program reasons that the user doesn't care about the identity of the Host and doesn't want to check it.

That said, in the upcoming version 6.9 we are adding 2-step verification (2FA) to the Host (uses Google Authenticator or similar app) . You'll be able to use that in order to strengthen your Host authorization.

Don't hesitate to ask me if you have other questions.

You are welcome :)

A bit later we'll add a documentation article on server migration.