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

[Seth David Schoen]

Keith Winstein writes:

> 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?).

Yes, I sure do, and I sure did. :-)

> 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.

That makes a lot of sense.

Traditionally anyone who can connect to the server as the same UID
as the mosh-server process could attach to it with gdb and find
its secrets.  In that case, any checks other than "the request is
coming from the same UID on the server" might turn out to be
ineffective, although some systems are starting to limit the ability
to ptrace a running process:

https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace

> 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.

Right, but that's a different property from "the newly observed mosh
session (w', x', y, z) is the continuation of previously observed
mosh session (w, x, y, z)" (hence "a user of IP address w' at time t'
is the same as a user of IP address w at time t"), which is the one
that Jacob and I have been worried about.  I think unlinkability of
sessions is legitimately a transport-layer concern in a way that maybe
concealing the existence of sessions isn't.

Linkability in this sense isn't really an issue for SSH just because
its connections are always dropped and re-established from scratch
when moving between networks.

It doesn't seem like the crypto to get this kind of unlinkability
needs to be very hard.

> 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.

Pure traffic analysis is definitely very powerful.  But there are surely
some hosts that have a lot of different users connecting (though I think
there's been a trend for individual servers to have fewer different users
than they used to).  An example that comes to mind is riseup.net, which
is used by activists who may fear that their connections are under
surveillance, and not want to have a way for an eavesdropper to recognize
them when they roam.

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