[mosh-devel] JuiceSSH STPClient Resuming

[Alex Elsayed]

Keith Winstein wrote:

> Hi Tom,
> (3) My guess of the way we would enforce this "use once" property is as
> follows. To resume mosh-client from a saved state, JuiceSSH would give it
> a filename where a different mosh-client had previously written out its
> saved state. mosh-client will open() this filename, check that the open
> succeeded, unlink() the filename, check that the unlink() succeeded, and
> then read and use the saved state. We should check to make sure this
> really does eliminate a race condition where two mosh-clients get started
> at nearly the same time with the same stored state.

I'd recommend using O_EXCL on the open. Even without it you ought to be fine 
- then both open()'s could run before the unlink(), but the unlink should 
fail in that case. The second check would catch it, but better to prevent 
the other instance from getting an FD at all. That eliminates the potential 
for a mistake in checking the return code.

> (4) Re: your ideas, once you start talking about copying the saved state
> around to different machines I get nervous! :-) We really do not have the
> crypto support to do this robustly, i.e. to prevent the same nonce from
> getting sent twice with different data. We may have to think about
> protocol modifications that allow the key to rotate if you are serious
> about wanting this. Otherwise it makes me uncomfortable.
> 
> Having the server detect this and deny one of the clients updates doesn't
> help -- once there are two different ciphertexts out there with the same
> key, same nonce, and different plaintext, it's basically game over. And
> the server may not be able to detect it if an adversary can prevent one
> set of datagrams from reaching the server.

One solution here might be to have JuiceSSH mandate that doing this involves 
*moving* the state file, rather than copying it - do the same 
O_EXCL/unlink() dance in JuiceSSH to block mosh from starting up with it, 
then read the FD and send it to another JuiceSSH instance. There'd need to 
be some way to rendezvous and send it on-demand rather than simply putting 
it in cloud storage, though, which raises the complexity.