Connection confirmation prompt

[Palakis]

Show a prompt when an unknown client attempts a connection to the server. Users will then have to choose what to do :

• Allow for X minutes
• Allow until OBS is closed
• Always allow (client fingerprint will be saved)
• Deny connection

[jnovack]

Thoughts:

• Where will the fingerprint be saved OBS-side? Is there a method for plugins to save data to disk?
• How will you capture the client fingerprint? Which set of variables will be used as the fingerprint?
• How will you ensure that does not change? Set a cookie on the client?

[Palakis]

Where will the fingerprint be saved OBS-side? Is there a method for plugins to save data to disk?

Yes, the same way as the plugin's config: using OBS' config file API.
What I need to check, however, is if it supports JSON objects as values.

How will you capture the client fingerprint? Which set of variables will be used as the fingerprint?
How will you ensure that does not change? Set a cookie on the client?

No idea right now... 😕 Maybe that "fingerprint" thing isn't possible. I need to do some research about this, and EFF's Panopticlick might be a good starting point.
As for the cookies, I don't think it works with WebSockets, even though WS is "based" on HTTP.

[jnovack]

I need to do some research about this, and EFF's Panopticlick might be a good starting point.

Unique is all or nothing. Otherwise you are just banking on lower odds.

As for the cookies, I don't think it works with WebSockets, even though WS is "based" on HTTP.

Because there is no layer between HTTP and the WebSocket (no intermediate database to pass a referrer or token), it might be extremely difficult.

The fingerprint would have to be sent via the HTTP daemon securely directly to the Websocket process, with t2t2, and abstracting that layer, it's not wholly feasible.

Especially, when I can run t2t2 on an internet site, but both my client, and my OBS on an intranet (as the websocket client will make a direct connection to OBS, not through t2t2).

Maybe that "fingerprint" thing isn't possible.

Without SSL and client certificate verification, I don't think it might be possible to do long-term (persistent across sessions) confirmation.

Best you can do at this point is some strange security features:

• Allow all connections
• Allow 1st connection, deny for others
• Allow 1st connection, prompt for others
• Prompt for all connections

You can at least get a session identifier (over the websocket) and obviously the IP, so we can whitelist (but again, do we want to do that at this layer? People will ask, but I don't believe we should.).

[Palakis]

Regarding the connection prompt, right now I believe that it will be IP-based at first, with the following options on the prompt:

• Allow this connection only, prompt for others
• Allow all connections from this address until OBS is closed
• Allow all connections from this address permanently

The whitelist can be based on an IP + User Agent pair, and any connection attempt from a known IP with a User Agent not associated with that IP will result in a removal of that whitelist pair. This can reduce a bit the possibility of IP based spoofing coupled with User Agent enumeration attempts.

[jnovack]

There are other ways to consume a Websocket connection, like Primus for Objective C that does not use a User-Agent. Basically, native iPhone Apps and native Android Apps can connect to Websockets without some of the usual mumbo-jumbo associated with Webbrowser connections.

[baroncrowley]

The whitelist can be based on an IP + User Agent pair, and any connection attempt from a known IP with a User Agent not associated with that IP will result in a removal of that whitelist pair. This can reduce a bit the possibility of IP based spoofing coupled with User Agent enumeration attempts.

I don't think this would work. For instance, when t2t2 connects to obs-websocket, it does so using your browser, so the IP will be 127.0.0.1 and it will bear your normal User-Agent. By using t2t2, that would (depending on user choice) temporarily or permanently open the user up to other third-party domains controlling obs-websocket, riding on the existing authorization that should have only been granted to t2t2. Plus, every time you update your browser, your User-Agent would change, requiring you to re-authorize.

A way to do this would be to have a randomly generated identification string sent along when connecting. A remote control site like t2t2 could generate the random ID and instruct the user's browser to present it as well as showing the ID in the web page so that the user can confirm that the connection they're allowing is from a website they wish to allow. For future connections, the string could be stored by the browser in a cookie or Local Storage. Looking at some documentation from Heroku, they suggest this method, and advise against using headers like Origin or other things that browsers would normally send for HTTP connections, since WebSockets are a bit of a different beast: WebSocket Security: Authentication / Authorization

The same security guarantees could also be achieved by implementing #424.

[tt2468]

Closing since we decided to go the route of asking users to create a password