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

[Keith Winstein]

Hi Seth,

Thanks for your kind words! I think we have sort of crossed paths
before (I think you know my high-school friend Meryl, and didn't you
write that DeCSS haiku?).

Right now most people probably just use mosh together with screen or
tmux, which works fine. We put the mosh-server PIDs in utmp so you can
see them with "who" and see which ones are attached or detached and
kill them if you like.

My preferred way to do "resumption" would be to have the user SSH in
again, contact the mosh-server over a Unix domain socket (and prove
they they are indeed the same user) and reinitialize the SSP
connection with a new key and a new series of sequence numbers. That
way we don't have to worry about repeating a nonce. If we start trying
to "journal" to disk, I'm going to worry about the possibility that a
past client sent an encrypted datagram with key X and nonce 14, but
for some reason the disk didn't get updated, and so when we resume
with a new client we end up sending nonce 14 with different data. That
causes security problems.

The long-term plan is probably the Unix-domain approach. (Also
probably some UI that warns you when you log in that you have N
detached sessions already running on the same host and offers to kill
them.) But given that screen/tmux already provide this functionality,
I don't think it's top of our list at the moment.

Regarding "linkability," I think we have made a decision so far that
Mosh (like TLS and SSH) only provides transport-layer security. We
don't try to disguise anything regarding the IP or UDP headers,
including the fact that a user on IP w, port x has a Mosh session to a
server on IP y, port z. I think you would need an IP VPN (with chaff
from decoy IP addresses) and a trusted anonymizer or Tor-like system
to do that properly.

Even with SSH (where everything goes to the same port number on the
server side), if you have automatic reconnection, an eavesdropper can
still follow you around pretty easily by seeing when sessions get
dropped and where they start up from again. (Especially if there are
only 2 or 3 users talking to the same host and they roam rarely and at
different times.) And what you say about TLS is correct as far as I
know.

Sorry I don't have a better story for either of these questions --
we'd love to have your help though.

Best regards, and thanks for getting in touch,
Keith

On Fri, Jul 6, 2012 at 11:35 PM, Seth David Schoen <schoen at loyalty.org> wrote:
> 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
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel