[mosh-devel] [mosh-users] Logging from mosh-server

[Keith Winstein]

Hello Jim,

I'd be happy to participate on IRC if you think that would be helpful --
just let me know the date/time.

You're in good company in suggesting the idea of renegotiation and (broadly
speaking) more bells and whistles in the protocol. And we may do this kind
of thing in the future, especially as we want to support proxying of a Mosh
session through a bastion host (letting the proxy track the authentic
roaming client, without giving the proxy the plaintext) and things like
keeping a session open over reboot.

But here's why we have been cautious: if you look at *why* SSH v1 was
fatally broken, and why SSH v2 (CBC mode) was broken, and why SSL v1 and v2
and v3 and TLS v1 were broken, and the various bugs in SSH (the
implementation) over the years, many of those breaks are attributable to
exactly the kind of options and bells and whistles that Mosh has really
resisted implementing.

The Mosh protocol is simple on purpose and that simplicity is partly to
credit with our good record so far -- in the nearly two years since Mosh
1.0 was released, we have not had a security vulnerability yet. I say "so
far" because inevitably we will have one at some point, just like everybody
else. But to date, Mosh's security record looks considerably better than
the implementations of SSH, SSL, TLS, and DTLS -- to put it frankly, how
much do we really want to emulate those systems?

>From a cryptographic perspective, Mosh (with its pinned AEAD mode) is
probably better than SSH's encrypt-and-MAC and also better than TLS's
MAC-then-encrypt. From a DoS perspective, both SSH and TLS are vulnerable
to the simple attack where a bad guy (not even an eavesdropper) sends a TCP
RST segment to end the connection, because SSH and TLS use cleartext TCP
for the session. Mosh of course applies integrity checking to the whole
datagram and isn't fooled by fake resets.

You're right that a bad guy who steals the session key from a mobile device
can "roam" the session elsewhere. Compromise of the client is a difficult
attack to counteract. A bad guy who steals the session key would probably
be able to use a nearby sequence number -- either by stealing the sequence
number at the same time, or just reading a recent sequence number off the
wire. (Like SSH, TLS, and DTLS, Mosh sends the sequence number in the
clear.)

A bad guy who steals an SSH session key can't roam the session, but they
probably don't need to -- in most attack scenarios that would let a bad guy
grab the session key, the attacker can just send a series of keystrokes to
install their own public key as trusted or curl | sh an arbitrary shell
script. (Either by sending them from the SSH client itself, or by send TCP
segments encoding the keystrokes. The sender does not need to receive the
acknowledgments for SSH to receive and pass the keystrokes to the running
application.) Of course Mosh is the same in this respect -- it's hard to
defend against a client compromise.

I like your suggestion to log crypto exceptions to syslog for the benefit
of an IDS, and I don't think it would be too hard for us to do this.

We're grateful for your interest in Mosh and I look forward to hearing
about your presentation. Please let me know if you'd like me to participate
in the Q&A and I'm happy to do it.

Cheers,
Keith

On Mon, Dec 30, 2013 at 8:36 PM, Jim Cheetham <jim.cheetham at otago.ac.nz>
 wrote:

> (sorry about the quoting, webmail isn't quite so flexible as my normal MTA)
>
> ------------------------------
> *From:* winstein at gmail.com [winstein at gmail.com] on behalf of Keith
> Winstein [keithw at mit.edu]
> *Sent:* Friday, 27 December 2013 6:21 a.m.
>
> > If the badguy is running as the user, they could start up a fresh SSH or
> Mosh (or anything) connection and log in from anywhere -- no need to hijack
> an existing connection, although they could do that too.
>
> I was more concerned about a key being stolen from the mobile device, and
> exfiltrated to the bad guy elsewhere. Where TCP-based connections require
> an attacker to spoof the original source address as well as the session
> credentials, mosh has only the session credentials; you don't seem to have
> any protection against large jumps in the sequence number as an indication
> of attack for example, or invalid packets for a connection coming from
> different sources. Looking from outside the application, from an IDS
> perspective, will help for some of this but won't help to understand the
> contents of the packets.
>
> > A sequence number is a 63-bit unsigned integer. There's no wraparound. A
> legitimate SSP sender will simply end the connection after two petabytes of
> data have been sent to preserve the authenticity and privacy of the AES-OCB
> stream. There is no key renegotiation.
>
> 2PB is of course immense, but in the long term I think you'll benefit from
> a renegotiation protocol, triggered by total data, or time, or any other
> anomalies in the channel that may come up, a bit like sshv1 does.
>
> > Some people in the #mosh IRC channel were discussing your upcoming
> presentation at linux.conf.au -- it looks very relevant! Would you be
> willing to share your conclusions with the list? We are proud of Mosh's
> security record so far and interested to work with the security community
> as people get more experience with Mosh.
>
> Ah, I've been found out, have I? :-)
> Not everything we've discussed here is direct source material for the
> presentation, but it has been really useful for me to build up an
> appreciation of what's happening. My general feeling is that you have done
> a decent job of coming up with a secure connection (for example, separating
> out the datagram layer), but you haven't been thinking of the sorts of
> multifaceted attacks that are used in the hostile world ... having said
> that, I'm not in the business of building PoC exploits.
>
> LCA presentations are usually livestreamed, and if I get the chance I'll
> make sure to pass the details on to this list. In any case the video &
> slides will be available soon afterwards. Given that I haven't quite
> finished writing it all yet, you'll have to wait :-)
>
> If you think it would be helpful, I could organise to have someone sit on
> your IRC channel during the presentation for the Q&A portion? Obviously
> this would be most useful combined with the livestreaming ...
>
> -jim
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20131231/0cb5ced7/attachment.html