The local websocket connection is unprotected, we should secure it
Music Assistant already proxies the connection + adds authentication
Clients can be outputs, controllers or metadata displays or visualizers
Do we only want to protect the server or also the client
Most clients are headless so no way to display a security code or whatever
What about approve a new client in the server ?
New client shows up on server → needs user confirmation
Showing 4 digit code or need to press button on the server [optional for DIY but mandatory for commercial devices]
Entire socket protocol encrypted, not the websocket messages
Noise encryption would be the easiest
Client HELLO + server HELLO (both report encryption support)
Client generates the key and sends it back to the server
→ either after the button was pressed
→ or after displaying some optional confirmation pin
→ once both ends confirm, client sends back the key to the server
→ client can only store up to 5 serverkeys
→ first message (HELLO) is always unencrypted
The local websocket connection is unprotected, we should secure it
Music Assistant already proxies the connection + adds authentication
Clients can be outputs, controllers or metadata displays or visualizers
Do we only want to protect the server or also the client
Most clients are headless so no way to display a security code or whatever
What about approve a new client in the server ?
New client shows up on server → needs user confirmation
Showing 4 digit code or need to press button on the server [optional for DIY but mandatory for commercial devices]
Entire socket protocol encrypted, not the websocket messages
Noise encryption would be the easiest
Client HELLO + server HELLO (both report encryption support)
Client generates the key and sends it back to the server
→ either after the button was pressed
→ or after displaying some optional confirmation pin
→ once both ends confirm, client sends back the key to the server
→ client can only store up to 5 serverkeys
→ first message (HELLO) is always unencrypted