[mosh-devel] thoughts on mosh

[Keith Winstein]

Hi Jacob,

Thanks very much for your kind words! Let me see if I can address the
points you raise:

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.

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.

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!

Best regards,
Keith

On Tue, May 15, 2012 at 9:55 AM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> Hi guys,
>
> I'm some guy who found your project, mosh, and I was really happy to
> find a great example of how to make a project. I think I'll use it as an
> example of inventing something awesome, punting to other tools that do
> specific jobs you're not interested in solving, and generally doing a
> great job at encouraging peer review. I especially enjoy your mockery of
> startup culture while actually being a shining example of Free Software!
> I rather enjoyed the mosh paper as well.
>
> I have a few thoughts about mosh - they mostly come from my interest as
> a Tor developer ( https://www.torproject.org/ ) but I also just wanted
> to say thanks for your smart work.
>
> First up - I was really happy with how easy mosh is to setup - I was
> able to get started in less than five minutes on two different platforms
> after reading half a man page. That's pretty great!
>
> I was a bit surprised by a few things - the first is that mosh binds to
> a range of high ports, I'd like it if by default it tries to bind to
> 5353, 53, 0 or even an ICMP socket; there's a good chance that those
> first two ports won't be blocked, the third requires some hacking and
> the fourth obviously requires some caps. I think it should be possible
> to get the caps required without being setuid but it's obviously a
> violation of your 'no special privileges' rule of thumb.
>
> I have set my mosh client to request port 5353 (mdns) and I've found
> that even on networks that tamper with DNS (transparent proxies), they
> don't seem to tamper with (!) mosh traffic.
>
> The second thing that surprised me was that mosh doesn't actually
> provide total confidentiality. In some very basic packet captures on my
> own laptop traffic, I saw a lot of zeros and some incrementing fields.
> If nothing else, I was surprised that this allows for trivial traffic
> analysis - watching a single server would allow you to correlate all of
> a given user's sessions across time and locations. I might be wrong
> about that but I suspect that is correct as the plaintext is all, well,
> plaintext. :(
>
> I suspect that this is going to cause mosh to be trivially filtered in
> places like China or Iran, places where I very much expect to use mosh
> because of latency issues.
>
> What do you think about actually providing confidentiality for
> everything? The packet lengths are already variable and the setup can
> happen indirectly, so once a session is up - the rest of the protocol
> could be a lot harder to classify, if you want... I'd sure like it!
>
> The third thing is that mosh is basically the perfect thing for Tor
> users with one tiny exception: UDP (!)
>
> Tor is for TCP connections and so UDP traffic will just leak or be
> dropped entirely - it depends on how the user configures things. I
> generally SSH to a given host and then attach to a screen session. Gah,
> if you thought SSH was slow directly, ha! It's not really very usable,
> as you can imagine. The trade off is location privacy and that is worth
> the cost in a lot of cases. If I had a single feature request, I'd be
> able to ssh over Tor, setup a mosh session and then have the remote mosh
> listener open a TCP receiver on the other end - this would allow me to
> Torify the mosh client entirely - something that would make my ssh + Tor
> + screen + irssi + mutt + bash experience really usable.
>
> What do you think of that? Is that something that might be possible as
> an addition in the future? I understand from the paper that REX is close
> to what I'd like but _only_ for the TCP transport. mosh is clearly
> better in every single way - from ease of setup to ease of use for the
> _other_ things I'd like to do, such as using my terminal!
>
> Sadly the lack of a TCP fall-back or proxy-able operation and the
> exposure of session information is something that would be worth
> discussing, I think. I feel like Tor is the perfect "worst case" network
> to try to work over...
>
> I've also cc'ed Roger, the creator of Tor as I bet he'd love to see Tor
> and mosh work together; I bet he'll have something interesting to say too.
>
> All the best,
> Jacob