<div dir="ltr">I'm working on a solution for this at the moment. And this is where I am at:<div><br></div><div>- We cannot use a use an external method to serialise the process because we are basically running the sessions as multithread due to iOS restrictions. Our only way seems to be to serialise "the hard way".</div><div>- To serialise objects, we would need to identify which ones are critical to restore a session from the client, and what others can just be ignored. It would also require to rewrite a few new constructors. I did a quick analysis and apparently it would "just" be: StmClient, Terminal::FrameBuffer (and probably DrawStates?), Network::Transport with Session, and TimestampedStates, etc...</div><div>- I do not want to use Boost so maybe ProtoBufs could be a better option in this scenario.</div><div>- Security concerns, like separating the key and storing it separately will obviously be a must.</div><div><br></div><div>Any other ideas on how to approach this?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 6:27 PM, Carlos Cabanero <span dir="ltr"><<a href="mailto:carlosecabanero@gmail.com" target="_blank">carlosecabanero@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for your response John!! The idea of writing the key to the keychain and in this way not putting all the eggs in one basket is great.<div><br></div><div><div>Initially, we were thinking if there was a way to implement a "mosh attach" without having to save the state of the process through an external tool (like CRIU) or serialising an object. As we have to implement it anyway, we didn't want to limit it to iOS and make it as an option for everyone. I understand now that this could increase the exposed security surface and maybe shouldn't be part of what Mosh should do out of the box.</div></div><div><br></div><div>What we will do then is to implement in our "extended" STMClient a new interface to extract the information to serialise before killing the session, and a way to restore it afterwards.</div><div><br></div><div>If anybody else has any ideas just let us know!</div><div>Thanks</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 12, 2016 at 7:47 PM, john hood <span dir="ltr"><<a href="mailto:cgull@glup.org" target="_blank">cgull@glup.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2/11/16 11:03 AM, Carlos Cabanero wrote:<br>
> Hi! We are a small team who have been working for the last few months on<br>
> a project that I want to introduce to you. Blink is a new mobile shell<br>
> for iOS built around Mosh. We created the terminal we wanted to have and<br>
> use all day, fully configurable (fonts! keyboard...) and with a great<br>
> UI, can't say much more than that right now ;)<br>
<br>
</span>Ooo! Interesting.<br>
<span><br>
> I wanted to reach out to you for two reasons, first to let you know the<br>
> work we have done, and second to discuss how some of our changes could<br>
> be pushed back to Mosh.<br>
><br>
> We have been able to compile Mosh for iOS successfully with a few<br>
> changes. For bootstraping, we rewrote the process to use our app<br>
> configuration and calls through an SSH lib. Then we transformed the<br>
> client into a library itself, that instead of using stdio is able to<br>
> receive other descriptors for input and output. We compiled it by<br>
> adapting the current makefiles and parts of the code that were not<br>
> compatible with current iOS policies. Everything is currently running<br>
> very well.<br>
<br>
</span>Looking forward to your pull requests and/or Github repo :)<br>
<span><br>
> We will obviously commit to the GPL and open source our work too. Some<br>
> of the things mentioned before make sense to be in the main branch. But<br>
> I wanted to focus the conversation on stopping and reopening Mosh<br>
> sessions (<a href="https://github.com/mobile-shell/mosh/issues/394" rel="noreferrer" target="_blank">https://github.com/mobile-shell/mosh/issues/394</a>)<br>
><br>
> I read about the security implications of making the nonce available. In<br>
> our case this is essential because the app might be killed by the OS at<br>
> anytime, and we would like to restart everything to its state when the<br>
> user reloads the app. We could consider iOS as a “secure” environment<br>
> for storage, and were thinking about always performing a “bootstrap”<br>
> through SSH to validate the server fingerprint before sharing it. We<br>
> think this last part could help avoid a Man in the Middle attack and be<br>
> a viable option worth considering in the main Mosh trunk too. I would<br>
> love to have your input on this because I’m sure you might have other<br>
> ideas worth exploring, or aware of other security issues. We would love<br>
> to put the resources to see it done.<br>
<br>
</span>This is unclear to me. What would you be sharing here? Are you talking<br>
about having the phone act as a keystore for other devices running Mosh?<br>
What MITM attack are you trying to avoid?<br>
<span><br>
> Thanks in advance!<br>
><br>
> PS: I discussed briefly with Keith and he suggested serializing the full<br>
> STMClient object. This would be easier too than what we though<br>
> initially, making the nonce and other required data available, and then<br>
> provide another "reboot from data" function in the client.<br>
<br>
</span>My thought is that putting "secure" in quotes is appropriate. If you<br>
dump sensitive Mosh state to the filesystem, then that state might be<br>
available in a number of ways that have to be considered:<br>
<br>
* Backups. I don't know if there is a way for an app to explicitly<br>
exclude files from backup.<br>
<br>
* I am fuzzy on the details, but I think iPhones allow filesystem access<br>
over the USB connection. But this suggests it's configurable by the app<br>
on iOS 8.3 and later:<br>
<a href="http://www.macrumors.com/2015/04/13/ios-8-3-ifunbox-itools-sandbox-app-access/" rel="noreferrer" target="_blank">http://www.macrumors.com/2015/04/13/ios-8-3-ifunbox-itools-sandbox-app-access/</a><br>
<br>
* Jailbroken phones. Of course when you jailbreak a phone, you're<br>
signing up for a different trust model, but it might be worth<br>
considering how Blink should work with that. And it might not be a<br>
trusted party that does the jailbreak.<br>
<br>
* Older, more permissive iOS versions. I assume this is mostly ruled<br>
out by App Store baseline requirements, but it's worth investigating.<br>
<br>
* Are there other places/points where you might want the device to<br>
forget about saved sessions, for example reboots or changes of security<br>
settings?<br>
<br>
KeithW's suggestion of serializing STMClient is good, but I'd add one<br>
extra idea to that: Before serializing/writing the object, remove the<br>
key, and put it in the iOS keychain. In iOS this appears to be useful<br>
because an app can only access its own keychain entries, and I'd hope<br>
that keychain access is tied to user authentication. It's also<br>
encrypted against backups. If there is a way to tie key lifetime to the<br>
serialized object, or the expected lifetime of sessions in Blink, that's<br>
even better.<br>
<br>
regards,<br>
<br>
--jh<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>