[mosh-devel] thoughts on mosh

[Jacob Appelbaum]

Hi Keith,

On 05/15/2012 04:52 PM, Keith Winstein wrote:
> 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.
> 

Yes - that is exactly one concern that I have - I outlined it a bit in
another email. It should arrive shortly...

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

This is true to a degree, I think. It is however a bit difficult as it
doesn't solve the linkability problems. If Alice starts ssh over Tor -
the exit node and anyone watching Alice's server will see a mosh session
start, tie it to her ssh client banner and then tie that to the mosh
session. It will then roam with her for as many Tor exits as she uses
over time. That means all of her circuits will be linked back to her
original login. That leads a trail of linkability that isn't great -
this is why we also disable TLS session resumption in the Torbrowser.

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

That's a good point - the UDP port number in itself is a kind of session
ID - the thing is, I think that's OK when compared with a monotonically
increasing nonce. Ideally with the TCP mosh, we'd get some kind of
multiplexing. mosh over ssh would do the trick, I bet.

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

I agree that it's not perfect but I'm pretty sure that the protocol
fingerprinting issue will be more important in the long run. That
fingerprinting will be much harder with fully encrypted payloads of
variable length. It's true that a dedicated attacker might still try to
link packets and they'd be playing a numbers game. They'd be right a lot
of the time but rarely ever certain, especially if Tor was in the mix.

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

Sure - we'd still want to consider correlation across exit nodes - we
don't want to make it easier for Alice to be tracked across nodes.

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

I think at the core there are two main issues:

1) make the protocol look like noise by reducing distinguishing features.
2) make it hard to pick out a given user's packets as they roam around.

The first is solved by ensuring that any data emitted from the
mosh-client is just a variable length, fully encrypted, authenticated
payload. Yes, the UDP header isn't encrypted but that's alright. In the
case of a TCP mosh, the header information isn't important at all.

As an example, Tor transports TCP streams, not connections, so the
header information would simply be _gone_ from the data available to an
attacker. The Tor exit node actually opens the connection, it doesn't
transport a SYN/ACK/FIN or other stuff.

The second is solved by ensuring mosh-client/mosh-servers works with Tor
or other SOCKS5/SOCKS4a proxies. This will ensure that there isn't a DNS
leak and it will allow a user to have location anonymity from the
server, as the server will see the Tor network.

The second is tricky because we want to compartmentalize the information
that the Tor network has access to in the short term and in the long
term. Over time, a client will likely exit through each exit node, it
might make sense to ensure that if a few exits get together, they can't
link a given user based on the nonce in the protocol. That would make
mosh a little less safe to use over such a network even if will still of
course be a remarkable improvement over all.

All the best,
Jacob