[mosh-devel] thoughts on mosh

[Jacob Appelbaum]

Hi Keith,

On 05/15/2012 01:34 PM, Keith Winstein wrote:
> Hi Jacob,
> 
> Thanks very much for your kind words! Let me see if I can address the
> points you raise:
> 

Thanks for replying - you must be busy, so I'll be brief...

> 1) We bind to 60000-61000 by default because, as you know, the goal is
> to run with no privileges. You can request 5353 or 53; I think 0 is
> going to take a raw IP socket (and so will ICMP). If we went into the
> realm of root and raw sockets, as Hari says we really could make the
> packets look like TCP which could be pretty cool. I'm not totally
> eager to insert 5353 as the default; even if it does work more often
> than 60001, it will only work for the first connection to a particular
> host, and we've already told everybody to open up 60000-61000.
> 

That makes sense. Reasonable too!

> 2) We do believe that the protocol provides confidentiality and
> authenticity for everything. The first 64 bits of the UDP payload is
> an incrementing nonce, and that should be the only thing you see in
> the clear. It serves the same purpose as the 32-bit TCP sequence
> number used in SSH and SSL/TLS (also obviously sent in the clear), or
> the 48-bit sequence number in DTLS, also in the clear. Generally
> speaking, you basically have to send the nonce in the clear.
> 

The main problem with this approach is twofold - the first is that the
the nonce increments in a way that allows Mallory to track sessions (and
thus users) across the internet by just watching a single server's
cipher text. Previously, I think it was the case that you'd get the ssh
client banner ( eg: "SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3" ) but not
much else. Now with mosh, Mallory gets that data and then can likely
link it with a fresh mosh session. That session id will uniquely stick
out and follow the user for days at a time. The second thing is that it
makes mosh traffic easy to distinguish as a protocol.

While the TCP sequence number is in the clear - it's something common to
all TCP traffic - mosh sticks out like a sore thumb, I think.

Any attacker worth their salt can also just grab some old session id
information, increment it, flip some bits in the packet and fuzz away.

I personally don't get why DTLS also made this choice. I don't really
buy the argument that it has to be sent in the clear - at best it serves
as a super lightweight way to decide if you should try to
authenticate/decrypt/process the packet, at worst, it doesn't do
anything against an attacker who can increment a field they have
observed, you'll just process the packet and throw it away. Or worse,
something else...?

> 3) We plan to support mosh-over-SSH pretty soon (probably the next
> version), which should solve help our a few use cases including
> mosh-over-SOCKS, mosh-over-HTTP-CONNECT-proxy, etc. I think this
> should be adequate for mosh-over-Tor as well -- does that sound
> reasonable? We will basically treat SSH like a (possibly high- or
> variable-latency) reliable link layer and run SSP over it, and you
> would be able to roam on and off the SSH connection, and restart the
> underlying SSH without losing your mosh connection. Happy to discuss
> this further if you have better ideas. I agree mosh over Tor would be
> pretty sweet!

That is pretty great - that solves the major issue I had which was
running mosh over Tor. :)

I suggest you use Tor for your simulations with a ProxyCommand with
socat - I do that like so:

  ProxyCommand socat STDIO SOCKS4A:localhost:%h:%p,socksport=9050

I bet it will be pretty intolerable if you thought normal SSH was bad!

All the best,
Jacob