[mosh-devel] Persistent Connections

Sat Nov 12 12:55:14 EST 2016

The core Mosh code in Blink is current with Mosh after the 1.2.6 
release, after my performance changes. That code creates a graph of 
differences/history via the smart-pointer shared Rows that it uses, 
though it doesn't explicitly use/look at the graph structure.  I would 
have to review the code to be sure, but I think you might lose some info 
(probably resulting in larger differences) if you didn't save all 
diffs.  I think you're safe blindly saving/restoring the entire list of 
states, and in the iOS client app save/kill/restore flow, it would be 
highly unusual for that complete list to take significantly more 
storage/compute than a more minimal list.  For that to happen, I think 
you'd have to do something like

start a session
lose connectivity to the server
type quite a lot or paste a large amount of text into the frozen session
switch away from the app and invoke the state-save code

In the common case, where Mosh is idle or the updates reflect normal 
typing, the list of states will have one large initial state, and the 
following states will be empty or very small updates.

I would guess the saved state is unlikely to exceed 2MB even on the 
large iPad Pro, especially if you're able to save the state as 
serialized, compressed Messages.  I recently did a small refactoring in 
the serialization and deserialization code paths that I think will help 
you access serialized but unencrypted Messages, actually.  I wasn't even 
thinking of this problem at all-- I did it on general principles-- but 
now I'm happy I did it.  See commit 255dc39.  If it doesn't, let me know 
and we can try and improve that.

It's not clear (to me) whether encrypting the session on the network, 
and the session state on persistent storage, are the same security 
problem/domain.  I think it might be better to use a separate, local key 
for encrypting the data at rest, and not reuse the session key, but it 
really requires some more thought and analysis.  I vaguely recall that 
the iOS keystore has a get-and-destroy operator as well.  If this 
actually exists and you used this in conjunction with a newly generated 
local key and maybe an OS boot-unique id each time you saved the state 
to persistent storage, I think that might nicely avoid the possibility 
of accidental session reuse.  If the iOS keystore has key options to 
make the key volatile (non-persistent across reboot) and/or local (not 
backed up, iCloud, etc), these would also be useful in this case.  
Again, Crypto is Hard, and these are ideas, not advice.

I remember looking over the iOS keystore API and writing some email or 
notes previously, but I can't find that now-- if I find a private note 
I'll add that to this discussion.

regards,

   --jh

On 11/9/16 8:03 PM, Keith Winstein wrote:
> Hello Carlos,
>
> Sounds cool! I think you will need to save every state newer than the 
> "throwaway number," because the other side is allowed to reference 
> that state (or any newer state that you have acked) in building a new 
> diff.
>
> My main fear with these saved states is that a user would somehow be 
> able to try "resuming" the same session twice, from the same save 
> file. That will result in the same sequence number being reused, which 
> would be cryptographically catastrophic. So any implementation that 
> allows "resuming" from a saved state must ensure that the saved state 
> is destroyed as part of the resumption.
>
> -Keith
>
> On Wed, Nov 9, 2016 at 3:14 PM, Carlos Cabanero 
> <carlosecabanero at gmail.com <mailto:carlosecabanero at gmail.com>> wrote:
>
>     I have started to work on “Persistent Connections” for Blink with
>     great success! For background, these are the related GH issues
>     (https://github.com/mobile-shell/mosh/issues/394
>     <https://github.com/mobile-shell/mosh/issues/394>) and
>     (https://github.com/blinksh/blink/issues/59
>     <https://github.com/blinksh/blink/issues/59>).
>
>
>     I hacked together - as in I have hardcoded most of the stuff - a
>     simple version that is able to save a session to disk and
>     reconstruct it given the previous key. Turns out it was all a lot
>     easier than I thought, without requiring hardcore object
>     serialisation. States (timestamp, sequence nonce and content) can
>     be dropped to disk as if they were going to be sent over the
>     network, and reconstructing the states to the initial
>     Terminal::Complete and Network::UserStream objects is
>     straightforward with the diff functions.
>
>
>     There is the question of how many states should be saved, from
>     reading the code I guess the answer is all of them, from my test
>     only the latest acked one was enough - but again, crappy test.
>
>
>     Another obvious security concern as the states contain information
>     from the terminal in a completely readable format. Could that be
>     encrypted again with the key before saving? In the case of iOS I
>     can save the secure key to the keychain. But I think that on top
>     of that, saving the session with a Passphrase might be a good idea.
>
>
>     I understand that this might only be useful in Blink, but any
>     guidance would be appreciated. In the same manner, if you change
>     your opinion, I'm more than happy to walk the extra mile and make
>     it work for everyone.
>
>
>     Thanks a lot!!
>
>
>     _______________________________________________
>     mosh-devel mailing list
>     mosh-devel at mit.edu <mailto:mosh-devel at mit.edu>
>     http://mailman.mit.edu/mailman/listinfo/mosh-devel
>     <http://mailman.mit.edu/mailman/listinfo/mosh-devel>
>
>
>
>
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20161112/1b0549ca/attachment.html