[mosh-devel] Persistent Connections

[Carlos Cabanero]

John, thanks a lot for the detailed feedback. It has been very useful to
continue :)

I'm definitely going to store all differences for states from the
"throwaway number". I'm currently saving/restoring the string diffs of the
states in order (so each state is a diff on the previous, and the first is
a diff on an empty terminal, etc...). I thought serialising the Rows graph
might be another way, but that turned out being a blackhole.

Maybe related is that I do not follow you on why we might need to serialise
with Messages though. My understanding is that Messages operate as a
wrapper on Packets to send over the network, and it would be a lower level
than we need to work with for this scenario. Is it due to some special
compression / encryption? Were you thinking about a way to feed the system
back with Messages and simplify object reconstruction?

Thanks again!


On Sat, Nov 12, 2016 at 12:55 PM, john hood <cgull at glup.org> wrote:

> 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
> > 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) and (
>> 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
>> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>>
>>
>
>
> _______________________________________________
> mosh-devel mailing listmosh-devel at mit.eduhttp://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20161117/f6ef883c/attachment.html