Voxior Remote Access - Security Implications?

191 views
Skip to first unread message

Tico

unread,
Mar 27, 2018, 2:07:16 AM3/27/18
to loxone-...@googlegroups.com
I've received an email from Voxior regarding a new feature that allows access to the Miniserver without port forwarding.

http://docs.voxior.com/voxior-remote-access-english/quick-start-instructions-voxior-remote-access

I'm using the Voxior Link product (Raspberry Pi device with custom firmware image) for voice control with Google Home and Loxone.

What I don't fully understand is the security implications for allowing the use of the Remote Access feature? On the one hand, it seems to improve security by removing the need for port forwarding to the Miniserver. On the other hand... I don't know how this works :~

Anyone care to comment?

Skarsol

unread,
Mar 27, 2018, 11:20:44 AM3/27/18
to Loxone English
The only way I can think that this would work is if that Link device creates a permanent open socket to their web services, then they can always connect to it without the use of port forwarding. Personally, I'd be more comfortable with a restricted port forward than with a perpetually open socket. In reality, both methods can be restricted to only allow access to their specific IPs, so it's kind of a 6 of one situation.


On Tuesday, March 27, 2018 at 1:07:16 AM UTC-5, Tico wrote:
I've received an email from Voxior regarding a new feature that allows access to the Miniserver without port forwarding.

http://docs.voxior.com/voxior-remote-access-english/quick-start-instructions-voxior-remote-access

I'm using the Voxior Link product (Raspberry Pi device with custom firmware image) for voice control with Google Home.

Tico

unread,
Mar 27, 2018, 7:27:14 PM3/27/18
to loxone-...@googlegroups.com
Thanks. It's a curious problem with 'connected' devices existing within your home network.

I'm probably not too concerned with some of the 'big brand' products, where I anticipate that their market value imposes behavioural constraints. Think Google and the risk/reward of nefarious activity.

But I don't have sufficient networking knowledge to fully appraise the risks with a product like Voxior. I don't intend to use the 'Remote Access' feature at present. As far as I'm aware, there's currently a link between Google Home to Voxior (the Link device is registered as a Google 'approved' device). The Link device is subsequently connected by internal IP to the Miniserver. The rationale being that this architecture prevents the Miniserver credentials being transmitted across the internet.

I'm open to learning about the risks or otherwise of open ports versus open sockets.

David

unread,
Mar 28, 2018, 3:41:24 AM3/28/18
to Loxone English
Also very interested to learn more about the benefits and risks of the different approaches. 
I have test ngrok to access devices in the house, but can't claim to understand it all ...yet!

Urban Marovt

unread,
Mar 29, 2018, 6:24:24 AM3/29/18
to Loxone English
Hello,

please allow me to jump in and try to explain a bit. As other mentioned before we have enabled remote access to your Loxone server without a need for port forwarding.

When configuring Remote Access, you get a personal link, known only to you, which you can use to connect to your server. As also mentioned before we have a persistent connection to VoxiorLink device. However, we are not using sockets but Secure Shell connection. You can contact our support if you need additional info - sup...@voxior.com.

Wishing you a great day.

Urban

Skarsol

unread,
Mar 29, 2018, 10:04:40 AM3/29/18
to Loxone English
So, to clarify, just because I'm interested, you're just setting up a permanent SSH tunnel?

Urban Marovt

unread,
Mar 30, 2018, 4:32:31 AM3/30/18
to Loxone English
Hi,

Thank you for your question.

Yes that is one step we take. After the created Shell tunnel we also put SSL certificate to assure HTTPS connection from your browser to our cloud service. From that point there is an SSH tunnel so the connection is protected the whole way.

I hope that answers your question.

Gregor Rebolj

unread,
Apr 3, 2018, 7:48:04 AM4/3/18
to Loxone English
Allow me to jump in and add some more details to the previous answers of my colleague Urban.

When creating the Remote access product we knew it needs to be super easy to use. Convenience unfortunatelly always trumps security and ordinary users always tend to move towards simplest options which are not necessarily secure. Most security products are not simple to use and are therefore used only by technical people. The product should also be transparent for the user, should work with existing apps without any modifications and should not require any additional custom software to be installed.
Remote access allows the family to access their smart home server and IP cameras remotely with existing apps. The access should be easy to turn on or off. On the other hand we also enable the family to create a separate access point for their installer and this access point should also be easily opened/closed by a non technical user.

As Urban mentioned tunnels are one part of the solution. We employ different tunneling techniques depending on the underlying protocol. Speaking of Loxone the Ngrok mentioned in the post above would in theory only work from browsers. Loxone Config, iOS and Android apps would not work. Similar is also true for KNX access using UDP.

But the real magic actually happens on the cloud.
Users can choose between two options:
- quick link access (e.g. https://l123456789012.vxrlink.de:80): can be used without any additional software on the client side - simply enter this URL as hostname and port in the app. HTTPS is used wherever possible/if app permits. Keep in mind that the URL is your secure key to your tunnel and you should keep it secret. The user still required username and password of course. You can simply generate a new one if the link gets compromised.
Most tunnels are hidden behind one common port and therefore cannot be scanned. We will be adding an additional layer of security soon which will only open the port to the client IP connecting with the right URL.

- VPN in the cloud: As an additional option the user can decide to connect to our VPN first before accessing their tunnels. A new account and configuration is generated for each user. Users can simply import the configuration and use VPN on demand functionality for a fully transparent usage. Only smart home traffic is routed through our VPN server and the phone only has access to the enabled tunnels - not your complete network as it used to be the case with normal VPN server at home setup.

A separate configuration is also made for the installer. Installers in the past suggested port forwarding or created a VPN access to the whole network. This way the owner has complete control of installer's remote access and installer only has access to the required infrastructure in the house and only when needed.

As mentioned the product is still in final stages of QA. We would love to get feedback from you on whether you see value in this new product and how you would improve it.

On Thursday, March 29, 2018 at 4:04:40 PM UTC+2, Skarsol wrote:
Reply all
Reply to author
Forward
0 new messages