[mosh-devel] Reattaching sessions after reboot; hiding session ID

[Seth David Schoen]

Hi,

I'm really impressed with mosh and super-happy it exists.  Nice work!

I just had my laptop lose power and reboot.  Of course when it came back
up my mosh sessions survived because the mosh server can't reject the
hypothesis that my clients are just roaming somewhere else and will
reappear in the future.  So I can't reconnect to those sessions as I
might prefer to.

Is there potential value in (and potential security harm from) an option
to save mosh credentials to disk in a .mosh-sessions file or something,
so that if your client machine reboots or your X session crashes you can
"reattach" by having a new client take over where the old client left
off?  I guess this would also create a prospect of migrating client
sessions from one machine to another, like screen -r -d with the mosh
server taking the place of screen.

In fact, a number of people have said that they think mosh largely
replaces their use of screen or tmux.  Some way to make ownership of
the session survive reboots or move from client to client would make
mosh an even more competitive replacement, but maybe at some cost in
elegance and security.  Or I could just use mosh together with screen...


Speaking of mosh session IDs and security, while looking at the archives
to see if this topic had been raised before, I saw the saw the thread
from May where Jacob Appelbaum raises the question of hiding session IDs
to stop eavesdroppers from determining that one mosh session is the
continuation of another session.  I think this could be an important
privacy goal in the long run, although I agree that other kinds of traffic
analysis may be powerful enough to make the benefits moot a lot of the
time.

The main privacy consequence I see is about where a passive network
attacker can determine who the owner of a roaming computer is.  In
other encrypted protocols, the attacker theoretically can't necessarily
do this easily because the behavior of different clients when setting
up new sessions may be indistinguishable, at least within a particular
client OS and client application version or something.  (On the other
hand, TLS session resumption is kind of sort of a little bit like what
mosh roaming does, and RFC 4507 session 5.8 says "unlinkability is not
necessarily provided" by session resumption -- I think even against a
passive network adversary, unfortunately.)

It seems like there are lots of ways known that one can prove knowledge
of a shared secret without letting someone who observes multiple proofs
recognize that the proofs relate to the same secret.  Some of them
are interactive, but others could be done non-interactively.

-- 
Seth David Schoen <schoen at loyalty.org>      |  No haiku patents
     http://www.loyalty.org/~schoen/        |  means I've no incentive to
  FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150  |        -- Don Marti