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
<carlosecaban...@gmail.com <mailto:carlosecaban...@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@mit.edu <mailto:mosh-devel@mit.edu>
http://mailman.mit.edu/mailman/listinfo/mosh-devel
<http://mailman.mit.edu/mailman/listinfo/mosh-devel>
_______________________________________________
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel
_______________________________________________
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel
