[mosh-devel] thoughts on mosh

[Keith Winstein]

Re: #2 (sequence number), a colleague points out that you could be
concerned not that an eavesdropper is getting any useful data out of
the session, but that an eavesdropper may be able to link packets
"pre-roaming" with packets "post-roaming" and trace the user's varying
IP address.

This is true but is not something that, I think, transport-layer
security can properly solve. You really need something like Tor (i.e.
something at the network layer) to actually disguise your IP address.

Even if we somehow didn't have to transmit a sequence number, an
eavesdropper could still identify the connection just by the server's
IP address and UDP port number -- I don't think the sequence number
adds anything here.

If we had a privileged daemon that multiplexed connections based on
cryptographic information (so they all came in to the same port
number), there is still just the fact that only a small number of
other IP addresses may be sending these kinds of packets to the server
at the same time. So tracing the user's IP address would be pretty
easy for an eavesdropper.

To solve that, I think you would either need convincing chaff passing
by the eavesdropper, from a variety of IP addresses, with the same
observable characteristics as the wheat  (this is basically an
unsolved problem afaik) OR you need to give up and use network-layer
methods to protect network-layer headers. This could mean either a
trusted anonymizing proxy or an array of semi-trusted proxies (e.g.
Tor).

I may be missing something and I certainly would welcome your and
Roger's further thoughts on the matter. Our goal is certainly to
satisfy the security community, and in some respects (e.g. the ability
to shift the timing of network packets without affecting interactivity
and the simplicity of other parts of the protocol) I think we have the
potential to be more secure than SSH or TLS.

Best regards, and thanks again,
Keith

On Tue, May 15, 2012 at 4:34 PM, Keith Winstein <keithw at mit.edu> wrote:
> 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