Warn users that Remote->Core connections aren't authenticated

Many people use laptops, and those laptops tend to appear on public wifi hotspots (coffee shops, etc). Based on Roon remote security and recent experience, connections from Remotes to Cores are totally unauthenticated, and no confirmation/approval is required on the Core, and users can’t change either of those settings.

I agree with some of the comments on the above community post that Roon’s choices here are at best irresponsible, and at worst they’re just waiting to become a bad press event when someone releases an exploit based on the Remote protocol that plays loud NSFW audio through every enabled Output (while the Roon user is at a coffee shop, no less). While that wouldn’t be disastrous, it seems unnecessarily embarrassing for users and Roon.

The most basic alternative is a simple one-time popup on the Core to approve or reject a new Remote, and this would nearly totally solve the problem with almost no impact to the user experience. Users who are on totally trusted networks could disable that. Another approach would be per-SSID or per-gateway-MAC trust settings, so users could trust any Remotes that connect while the Core is connected to their home SSID.

I think that’s an incredibly high return on the implementation effort. However, this feature request/bug report is for an even simpler change: warn users that their Cores are insecure. I almost guarantee that right now, a Roon user is sitting in a coffee shop, on public wifi, with Roon Core running on their laptop. There’s no reason for this.

The Architecture and Knowledge Base should both be updated to cover authentication or the current lack thereof, and to explain Roon’s thinking on the matter. Right now, searching Roon’s docs for “password” and “authentication” will turn up nothing authoritative. One needs to dig pretty deep on the community site to find the post above.

The feature request: If you’re going to intentionally omit authentication on devices that at least some users will use on public networks, it seems like the absolute minimum is to make users aware of that fact in the docs and setup.

Finally, if this request mischaracterizes Roon’s current Remote-to-Core authentication, please say so. My summary is based on what’s in the docs (almost nothing), firsthand experience (no shared credentials or tokens), and the other community thread.

2 Likes

Absolutely still astonished by the fact the remote are “free” to reach the server just installing them on a device.

Still don’t understand people that try to explain me reasons for leaving things as they are now.

Even a PIN could be good but now the situation is unbealiveble.

1 Like

The thing that baffles me is that this is fixable with only a change to the Core UI, not the Core<->Remote protocol or Remote UIs. The Core could pop up a “A new Remote is connecting from 1.2.3.4. Trust it?” dialog box for connections from a never-before-seen Remote[1] and put this risk to bed. And, of course, that option could be disabled for headless fixed-network Cores.

It’s one thing to balance security against UX and protocol complexity, but in this case, there’s not a tradeoff. This is implementable with no impact to UX or protocol complexity.

[1]: Best case, the Core would identify a new Remote by GUID or something else that’s not guessable. However, even if that doesn’t exist and the Core only prompted for a Remote source IP+network (that is, SSID, interface name, or gateway MAC) which it hadn’t seen before, that would all but eliminate practical attacks.

1 Like

Even easier and without messing with password.

Also the chance to associate and disassociate remotes when someone wants.

That’s too simplistic, as it would a problem for those with headless Cores.

I believe a Core / Remote authentication protocol would be required. I suspect this will come when Roon implement mobile remote access.

For now on a private network, that Roon is designed for, I think the risk is minimal.

Firewall protection if the Core is hooked up to public network, should offer adequate protection.

1 Like

Hmm. I explicitly addressed that with:

It seems like security isn’t mutually exclusive with headless Cores. What’s your take, Carl?

Also, what’s your assessment of the use case that I listed? Namely, it seems like more than 0 users install Core on laptops, and if that’s the case, those laptops are almost certainly mobile.

If you disagree and have numbers on the % of installations on laptops (or even a proxy for it, like display resolution), perhaps we could debate facts instead of opinions.

Right now, Roon’s reply comes across as dismissive, and moreover, not a very compelling factual argument. I’m sure not saying that Roon should blindly honor my opinion, but Carl’s reply didn’t address any of my main points (why a Core-only popup wouldn’t work, it could be disabled for headless Cores, if some % of Cores are on laptops then those laptops are likely to visit coffee shops, and at least warning/notifying users). If we’re going to bother debating a feature, let’s debate it as peers.

While I don’t run Roon Core outside of my private home network, if I were running Roon on a laptop that connected to pubic Wifi or whatever, the scenario I would be most concerned about (albeit highly unlikely) would be someone (most likely an acquaintance, e.g. at work, who knows I use Roon) connecting and surreptitiously deleting content or editing metadata in my Roon library.