It uses ssh as the authentication and authorization channel to set up the socket on the remote machine. I don't want to make too many pronouncements as I haven't used it, but surely that's an example of being conservative with security behavior, not cavalier.

That said, I think the single biggest annoyance for me with ssh is the connection setup latencies (something like ... 9 round trips and a by-default-rdns-lookup I think?). This thing can only be worse in that respect.

Well, it helps in that you need to initiate a connection much less often. Once you have a connected mosh session, it will transparently roam with you, across suspend/resume or changing networks, as long as you like.

But yes, it can't help with the initial connection, which has to be bootstrapped over ssh.

Any time you are moving from one IP address to another, it better have some damn good security or else anyone will be able to hijack your session.

For some definition of "damn good" I guess. All security protocols can have holes. But a trivial session key is hardly rocket surgery. And spoofing attacks (which I assume is what you're talking about) don't require moving between one IP and another anyway.

If you are opening multiple ssh connections to the same host, you can add the following to your .ssh/config file

# Multiplex connections if there is more than one Host * ControlMaster auto ControlPath ~/.ssh/master-%r@%h:%p

It's a replacement in the sense that, whenever you'd type 'ssh', you should type 'mosh' instead.

Exactly. It just happens to use ssh to bootstrap itself.

There are 101 million ways to screw these kinds of protocols up, that's why I'm sceptical. There are too many avenues to list, but here are a few:

* Security product written in C++, leveraging 2 huge libraries (Google protocolbuffers, Boost)

* One man band by the looks of it

* Includes its own private crypto code (has rijndael-alg-fst.cc been vetted for timing issues?)

* Implements its own private crypto protocol (has it been vetted for replay attacks? padding attacks? [insert 20 years of perplexing bugs confounding the greatest minds in computer science]?)

etc.

And besides all that, this page is begging you to download it. It ticks every box: sexy Bootstrap design, prepackaged installers for every OS, and not one mention of a single downside! That raises the question: what is the author's agenda? (At a guess, school cred, but still, this isn't reason enough for me to swap out something as critical as SSH)

We certainly welcome your eyes on the code. Any novel secure datagram protocol is going to have to prove itself; this one is no exception. Of course we think the radical simplicity of the design is an advantage, but of course others have thought that and have been wrong. So it's going to take time for everybody to get comfortable with it.

Regarding the Web site, I think Hacker News is able to take a little ribbing. You guys are always throwing up these twee Web sites; surely the free software community can have a little fun with the genre. :-)

From my limited perspective the code actually looks quite clean (although often this is the very quality that hides the worst of bugs!). One issue with UDP is dealing with NATs and firewalls (for example, in public WiFi hotspots where SSH is often permitted, but random other ports are not). The dependency on protocolbufs seems a little redundant given the size of your protocol (that is one huge library to import for the sake of 24 fields).

Will definitely give this a whirl at some stage, as the feature set is quite compelling, and assuming it gets healthy reviews from the talented crypto folk on HN. :) Good luck!

It’s good to be careful and perhaps a little skeptical when there’s a new approach that’s not the tried and true ssh.

The quote from the homepage tells me they get it:

Why you should trust Mosh with your remote terminal needs: we worry about details so obscure, even USENIX reviewers don't want to hear about them.

Agreed on the protocol buffers; that's a huge overkill for what it is used for.

    > Includes its own private crypto code (has 
      rijndael-alg-fst.cc been vetted for timing issues?)

This is as far as I can tell the original rijndael-alg-fst.c reference implementation, which has cache timing issues in the S-Box table lookup.

The crypto/aes/aes_x86core.c implementation from OpenSSL uses pre-fetching as a countermeasure.

[Edit: Better formulated as a question? :-)] Since OpenSSL is a long tested and optimized library, why did you decide to ship an own aes implementation?

We'll have to study this. The practical reason for using the rijndael reference code is that ocb.cc is only written against three interfaces: OpenSSL (which we can't ship currently for licensing reasons -- we depend on GPLed code), the rijndael reference implementation, and compiler AES intrinsics (which we don't have on most architectures).

Down the road we may end up making a shim to use GnuTLS or figuring out how to ship as GPL+OpenSSL exception.

The practical exposure to information leakage via timing attacks is pretty controlled, since we just ignore any datagram that fails the authenticity check and we generally only send outgoing packets per a timer (whose smallest value is 1/50 second).

OpenSSL also had 8 vulnerabilities in 2012 -- http://www.openssl.org/news/vulnerabilities.html.

Maybe this is the place to plug http://nacl.cr.yp.to/, by at least one author who has an excellent track record of shipping software with very few vulnerabilities. And who discovered the S-Box cache timing vulnerability mentioned upthread.

If you have the freedom to invent your own encrypted network protocol, instead of having to be backwards-compatible with SSL or SSH, you should seriously consider NaCl as an alternative.

Plus, in NaCl there's a work-in-progress implementation of CurveCP protocol http://curvecp.org/, which works over UDP and seem to be a good fit for something like mosh.

>Security product written in C++, leveraging 2 huge libraries (Google protocolbuffers, Boost)

Protocol buffers is heavily scrutinized and as for Boost, the way it's designed means that it only pulls in what you use. The project seem to only use very little of Boost anyway, so I wouldn't bother too much about it.

More surprising, I can see it does not use Boost.Asio for networking (strange ?). It seems to use Boost for things like Boost.Lambda (deprecated with C++11) and typeof.

I think the project could benefit from leveraging the Boost libraries more or just not use them at all.

Examples: use Boost.Spirit for Base64 and replace the custom made parser. Don't use malloc to allocate raw pointers but use strings, vectors or smart pointers. Replace the networking code with Boost.Asio (which is portable). etc.

Yeah -- we use ssh to authenticate the user and log them in and start up the mosh server (an unprivileged helper process). Then we shut down the SSH connection and establish a direct (roaming) connection over UDP.

That does not work. It seems to me that you need to install mosh server, which doesn't have much documentation at this moment.

I just installed the mosh client, and replacing ssh with mosh command alone doesn't work. By not working, I meant the error message is "/opt/local/bin/mosh: Did not find mosh server startup message."

Hint: you need to install mosh on both client and server. That error message means you have the client installed locally, but not remotely.

I installed Mosh on both client and server and still got this message :-/

I'm downvoting you not because of your stance on Mosh, but because you're being, in the technical term: "A dick."

Generally speaking, I'll tend to downvote anyone who says something like "Go ahead and downvote me" unless the post is otherwise insightful enough to be worth an upvote.

It doesn't sound like it is tunneled within SSH --- rather, it uses SSH as a sign-in method to launch mosh's own protocol handler that uses its own socket. Once mosh launches, ssh exits.

Since it uses ssh for authentication, it has eliminated some of its peer-review problems.