Protect tokens against spoofing by the room server

[staltz]

Suppose the room server is malicious and once a remote peer tries to use a tokenized alias URL, the server just responds false to the brokerAuth.request() (pretending that the alias owner is offline) and then proceeds to abuse that token to introduce another evil buddy to consume that token and force the alias owner to follow the evil buddy. Boom. :boom:

We could try to sign or encrypt the token somehow, but in general, the room server MUST NOT know what the plaintext token is. On the other hand, how are we going to do that? The first step is the remote peer visiting the tokenized alias URL in a browser and the web browser replying with an SSB URI, which will then open the SSB app and make the muxrpc calls.

[staltz]

Idea: use URI fragment part similar to how wormhole.app does it.

Like this:

The tokenized alias URL could be https://{alias}.{domain}/?encryptedToken={et}#{key} and the #{key} part is not sent to the room server. Then, when the page loads, some JavaScript picks up window.location.hash (Wormhole actually does this), which corresponds to the key, decrypts the token, and puts the decrypted token in the SSB URI that is then used to open the SSB app.

The SSB app then will see the decrypted token, and before sending the muxrpc call to the room, it will asymmetrically encrypt the token so that only the alias owner can decrypt it.

[mplorentz]

Then, when the page loads, some JavaScript picks up window.location.hash

If the room server is malicious couldn't it include malicious Javascript to pick up the hash to read window.location.hash?

[staltz]

Yes, but that argument also applies to wormhole.app. One way of mitigating it is opening the source for the page before allowing JavaScript to run on the page. A bit weird, yeah. I wonder what @feross thinks about the security of wormhole in that regard.

[staltz]

I made a commit today that addresses this vulnerability. It adds encryption and signatures to all muxrpc APIs the room is brokering, to prevent the room to have the power to replace the arguments of those APIs. The browser-side is still sensitive to what we said above, but alternatively there is also the possibility to copy-paste the tokenized alias URL https://{alias}.{domain}/#{token} into the SSB app, then the SSB app can extract token from the URI fragment, and call just https://{alias}.{domain}/?encoding=json, leaving the room server with no chance to get the token.

For UX, clicking the link is easier, but if someone wants extra security they can copy-paste it instead.

[feross]

It's true that with this design the potential for malicious JS to steal the key exists, but this is unfortunately the best we can do with current web technologies. That said, this problem also exists in native apps such as Signal, etc. that contain auto-updaters. When the code on the client can change out from under you at any time, or when you haven't had time to audit the code before using it, you're trusting the author of the software to be honest.