Any client can connect over https to any server. Who authenticates that a particular user can access my system? What’s the key material? Who defines and controls it? Is it your forum login? Roon account login? ssh keys? Something entirely different, perhaps home-brewed by roonlabs as is their penchant? Once authentication is done over https, does the music stream over https too, or does it use their proprietary RAAT protocol over another port that has a completely different set of security implications?
These and other relevant questions are just rhetorical when posed to you here, @Steve_Brueck. Conjectures from roon users aren’t illuminating. (Unless you have access to the code?) The actual details need to come from roonlabs.
I don’t follow this logic at all. Roon didn’t trigger a failure mode. The vendor of the home router/gateway did when they enabled/disabled UPnP by default (typically enabled).
You seem to know your stuff, I don’t, so my question if you are happy to answer it.
Does the security risk appear on updating the core version to 2.0, or does it only manifest if I update the core version to 2.0 and give access to the ARC app?
I also don’t understand if the update is mandatory, if it is it has meant my dad shifting his core from his Mac desktop to a newer laptop.
Roon doesn’t publish the spec for their network protocols. I know, I’ve asked. Would of made my life a lot easier when I wrote the Wireshark dissector for the Roon Discovery Protocol if they did!
But even that isn’t enough. While a spec can tell if you the design is secure, it does not tell you if the implementation is secure. There can still be all kinds of bugs in the code that Roon wrote or 3rd party libraries they’re using.
Honestly, if you want to know the answer to “Does Roon ARC create a security risk to my home network if I expose it to the Internet?” I can answer that with 100% certainty: YES.
And you’ve identified why Roon isn’t responsible here. That vendor is failing open to make it easier on their users. Users accept this because they don’t want to be bothered. In the case of OP they are not “default” user. They know what UPnP is and they have disabled it. Lack of information, even lack of information that a service is going to request a port, fails that service closed.
I’d like to see Roon provide more info (some great questions asked in this thread) but I disagree with the assertion that Roon needs explicit consent as it relates to ARC and UPnP. No other software does this. These automagical provisioning protocols exist for a reason.
I don’t know how much of a security risk 2.0 poses because roonlabs hasn’t given us any information about how it handles security. I don’t know, for example, if installing 2.0 but “setting the ARC port to 0” removes all possible vulnerabilities despite claims being made on the forum.
You can stay on 1.8, but will be prompted to update to 2.0 whenever you run a remote.
You can install a special version of 1.8 core and remotes (called 1.8 build 1126 “production1x”) that will not prompt you to go to 2.0 when you run remote. (It’s also refered to as “roon (Legacy)”). This might be a good thing to install since it’s easy to accidentally let the 2.0 upgrade install itself and then your dad’s old machine might not work with the upgrade, assuming that’s why you talked about him shifting to a newer machine.
roonlabs says they will keep 1.8 build 1126 available along with 2.0, but won’t support it after the end of the year, so no updates, bug fixes, and so on. See this article for instructions or this thread for a discussion of it.