[mosh-devel] Presenting Blink Mobile Shell (iOS)

[john hood]

On 2/11/16 11:03 AM, Carlos Cabanero wrote:
> Hi! We are a small team who have been working for the last few months on
> a project that I want to introduce to you. Blink is a new mobile shell
> for iOS built around Mosh. We created the terminal we wanted to have and
> use all day, fully configurable (fonts! keyboard...)  and with a great
> UI, can't say much more than that right now ;)

Ooo!  Interesting.

> I wanted to reach out to you for two reasons, first to let you know the
> work we have done, and second to discuss how some of our changes could
> be pushed back to Mosh.
> 
> We have been able to compile Mosh for iOS successfully with a few
> changes. For bootstraping, we rewrote the process to use our app
> configuration and calls through an SSH lib. Then we transformed the
> client into a library itself, that instead of using stdio is able to
> receive other descriptors for input and output. We compiled it by
> adapting the current makefiles and parts of the code that were not
> compatible with current iOS policies. Everything is currently running
> very well.

Looking forward to your pull requests and/or Github repo :)

> We will obviously commit to the GPL and open source our work too. Some
> of the things mentioned before make sense to be in the main branch. But
> I wanted to focus the conversation on stopping and reopening Mosh
> sessions (https://github.com/mobile-shell/mosh/issues/394) 
> 
> I read about the security implications of making the nonce available. In
> our case this is essential because the app might be killed by the OS at
> anytime, and we would like to restart everything to its state when the
> user reloads the app. We could consider iOS as a “secure” environment
> for storage, and were thinking about always performing a “bootstrap”
> through SSH to validate the server fingerprint before sharing it. We
> think this last part could help avoid a Man in the Middle attack and be
> a viable option worth considering in the main Mosh trunk too. I would
> love to have your input on this because I’m sure you might have other
> ideas worth exploring, or aware of other security issues. We would love
> to put the resources to see it done.

This is unclear to me.  What would you be sharing here?  Are you talking
about having the phone act as a keystore for other devices running Mosh?
 What MITM attack are you trying to avoid?

> Thanks in advance!
> 
> PS: I discussed briefly with Keith and he suggested serializing the full
> STMClient object. This would be easier too than what we though
> initially, making the nonce and other required data available, and then
> provide another "reboot from data" function in the client.

My thought is that putting "secure" in quotes is appropriate.  If you
dump sensitive Mosh state to the filesystem, then that state might be
available in a number of ways that have to be considered:

* Backups.  I don't know if there is a way for an app to explicitly
exclude files from backup.

* I am fuzzy on the details, but I think iPhones allow filesystem access
over the USB connection.  But this suggests it's configurable by the app
on iOS 8.3 and later:
http://www.macrumors.com/2015/04/13/ios-8-3-ifunbox-itools-sandbox-app-access/

* Jailbroken phones.  Of course when you jailbreak a phone, you're
signing up for a different trust model, but it might be worth
considering how Blink should work with that.  And it might not be a
trusted party that does the jailbreak.

* Older, more permissive iOS versions.  I assume this is mostly ruled
out by App Store baseline requirements, but it's worth investigating.

* Are there other places/points where you might want the device to
forget about saved sessions, for example reboots or changes of security
settings?

KeithW's suggestion of serializing STMClient is good, but I'd add one
extra idea to that:  Before serializing/writing the object, remove the
key, and put it in the iOS keychain.  In iOS this appears to be useful
because an app can only access its own keychain entries, and I'd hope
that keychain access is tied to user authentication.  It's also
encrypted against backups.  If there is a way to tie key lifetime to the
serialized object, or the expected lifetime of sessions in Blink, that's
even better.

regards,

  --jh