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.cheet...@otago.ac.nz> wrote: > (sorry about the quoting, webmail isn't quite so flexible as my normal MTA) > > ------------------------------ > *From:* winst...@gmail.com [winst...@gmail.com] on behalf of Keith > Winstein [kei...@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 > >
_______________________________________________ mosh-users mailing list mosh-users@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-users
