JSON-RPC: Authentication / Open-ness

[hoffie]

The discussion about authentication for the hopefully (?) soon-to-be-merged JSON-RPC implementation in #1975 starts getting longer, so I'm replying here to keep the PR focused on the code.

Jamulus sends billions of unencrypted UDP packets flying around the globe. There's no gating, security, encryption, validation, etc for client connections

Right. It's a controversial topic by its own. However, I think the situation with regards to JSON-RPC is clearer (at least to me): We are introducing an API which (also) contains admin functionality (e.g. recorder control, change of welcome message HTML, etc.) and might easily be extended to cover even more use cases. Therefore, I can currently think of these two options:

• Restrict the API as much as possible (e.g. by binding to localhost), as the current code already does. Plus, document the fact that there is no way to lock this down any further wrt local misuse.
• Allow opening the API to non-localhost addresses, but enforce authentication in order to avoid misuse.

Security has not really been a part of Jamulus DNA and it has been delegated to admins who need the security to implement it.

There's plenty of precedence out there for commercial-grade server software allowing binding to any interface without security or encryption (MongoDB comes to mind).

Yes, and the precedence implies (at least in my bubble): Admins are regularly bitten by this, because they've never known about that open-ness, forgot about it or changed a minor, "unrelated" part (e.g. firewall rules).
https://www.securityweek.com/thousands-mongodb-databases-found-exposed-internet
https://www.bleepingcomputer.com/news/security/mongodb-databases-held-for-ransom-by-mysterious-attacker/

I think a choice should be made as to whether the issues surfaced are the responsibility of the Jamulus developers or of the server operator who makes a conscious choice to enable this feature. An admin needs to know what they are doing if they are going to enable this feature -- just as they would for any server.

I agree that this is how it should be. Nevertheless, in practice, you'll find lots of server admins which work solely based on tutorials with little understanding of networking or other basic concepts. The general increase in abstractions pushes this mindset. That's why I like the "prevent people from shooting in their foot" approach.

BTW, simply encrypting the JSON-RPC payload with the preshared key would solve both the authorization and encryption issue - but I don't know if this is part of the rpc spec.

I don't think it's part of the spec and it would probably require specific API clients to work with it like that. The idea of the authentication PoC works on the application-level part of the spec.

Originally posted by @Rob-NY in #1975 (comment)

cc @Rob-NY @ann0see @dtinth

[ann0see]

My standpoint now is:

1. introduce basic (required) authentification
2. Bind on localhost by default (but allow binding on 0.0.0.0 or [::] with a warning message)

We should consider security more seriously.

[QJKX]

There is a third option - a Unix socket.

Access control is delegated to OS file permissions.
Creating the socket by default no longer meaningfully increases the attack surface area, assuming conservative default file permissions (correct use of umask).

It's a much smoother experience for software on the same host that uses the JSON-RPC interface - it can expect the socket to be in a default location and there's no longer a need to share a password through a config as a password is unnecessary. Port clashes aren't possible.

[dtinth]

Thanks for the suggestion. I had considered this option before, but I had concerns about Windows support. Without enough resources to do further research, prototype, and test it on an actual Windows machine, I decided to use TCP socket to keep the implementation simple.

I think supporting Unix socket would be a great addition.

Note, as of writing, a basic authentication mechanism has already been implemented. You can read about it in the docs. https://github.com/jamulussoftware/jamulus/blob/r3_10_0/docs/JSON-RPC.md