Roon should create a steady secure tunnel instead of relying on port forwarding

You know, you can do this yourself. ARC works over VPN connections. So instead of forwarding the ARC port on your Roon server, set up a VPN tunnel and use it with your phone. ARC will work with that. Now the security issue is up to the VPN provider, which probably employs more security experts.

I hope that is a joke…

We are talking about consumer ready solutions. Those should be both easy and straightforward to use as well as being safe.

Another problem is that we do not know what kind of protocol is transported over this connection. It is an undisclosed protocol over TCP. Is it encrypted? Is it inside TLS? I did not find any information.

1 Like

That’s wrong, but I will not get into details :slight_smile:
ZTN is an architecture, not a solution.
and this is an Audio forum :wink:

Another (more elegant) suggestion (which is one of the tools in the ZTN arsenal) and works with Ipv6 and Ipv4: use UDP pinholeing, like Teamviewer does :wink:

It is described here (for TeamViewer)

and in Wikipedia :wink:

@danny has said it’s encrypted. Various folks have snooped the wire and found out it is using TLS. True, it’s kind of hard to find out what “we know”, but it’s all out there.

TLS is nice, but doesn’t solve all security issues. Some questions that come to mind are:

  1. How are client connections to the Roon ARC server authenticated? It is very rare that this is done via TLS Client Certificates and is much more often done over TLS. But in such cases, TLS doesn’t prevent anyone from trying to connect to Roon via ARC.
  2. Are there any bugs or design flaws that allow an unauthenticated user from gaining access they should not have?
  3. Once they have access, can they use that to do things like run arbitrary code on my Roon Core?

This is probably a greater concern to me than some “bad guy” connecting to my Roon Core via ARC and then judging me based on my musical tastes.

Edit: Since Roon seems to run as root (at least on Linux), this is very non-optimal. Roon should be dropping privileges or running as a non-privliged user so if there are any bugs in the code, an attacker has a harder time causing havoc.