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

[Alex Chernyakhovsky]

> you're using only a single factor to represent permission to connect to a server

I'd like to point out that this is basically true of both SSH
(encrypt-then-MAC) as well as TLS (MAC-then-encrypt); you're just
using two separate secrets negotiated with the server because each
algorithm (encrypt, MAC) needs its own keys. In the event of client
compromise, all of the necessary information to hijack the connection
is compromised regardless of the mode. Utilizing SSH for
authentication *allows* mosh to rely on existing multi-factor
authentication schemes without any modification.

Sincerely,
-Alex


On Wed, Jan 1, 2014 at 11:06 PM, Jim Cheetham <jim.cheetham at otago.ac.nz> wrote:
> From: winstein at gmail.com [winstein at gmail.com] on behalf of Keith Winstein
> [keithw at mit.edu]
> Sent: Tuesday, 31 December 2013 8:47 p.m.
>> I'd be happy to participate on IRC if you think that would be helpful --
>> just let me know the date/time.
>
> Currently I'm on at 13:20 WST (Perth, Australia) on Thursday 9 Jan. I don't
> know your timezone, but that'll be between 9pm and midnight on *Wednesday*
> for the US
> (http://www.timeanddate.com/worldclock/fixedtime.html?msg=lca2014mosh&iso=20140109T13&p1=196).
> If you could start up a new IRC channel for this, I'll pop it up onscreen
> during the Q&A.
>
>
>> 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.
>
> What makes me uncomfortable at the moment is that if feels like you're using
> only a single factor to represent permission to connect to a server (the UDP
> port and sequence numbers seem to be too public to count as reliable
> factors), whereas traditionally we spend time on
> multi-factor-authentication. It's a handwave to say that you defer to ssh
> for authentication, because that's only true for starting the server; at
> every point after that your key represents full authentication. Everyone
> else's session keys are tied up with the TCP source, which isn't the
> strongest factor in the world but is better than nothing.
>
> However, just because I'm uncomfortable with it doesn't mean I'm right :-)
> In order to have a proper argument with you about the datagram layer, I'm
> going to have to do a lot of research & learning (or convince some people I
> know who already know this stuff to do it for me!).
>
>> 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.
>
> Compromise of the client device is basically undetectable *by the client*;
> in general when we look at security from a higher level we are profiling
> behaviour between systems and looking for that to change. The server is the
> best-qualified point at which to manage this sort of thing (not least
> because the server can decrypt the packets), which is one reason why more
> logging will help tremendously. Perhaps having the logging policy in an /etc
> file would help people to set a local 'default' nicely, without end-users
> having to remember to invoke it every time.
>
> -jim
>
>
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>