Closed kmcallister closed 12 years ago
Perhaps the best solution would be to use a public-key-based technique to have mosh rekey every 10 minutes or something (overwriting the old key from memory). That way the yakuza will only be able to get the most recent 10 minutes of traffic.
I don't think that helps very much. mosh-client
could get swapped several times to several different disk blocks, each retaining a record of the session key at that moment.
Rekeying might be a good idea in general, but it would complicate the crypto story significantly, so I am skeptical. A paranoid user of Mosh (+ screen or tmux) already has a simple way to rekey at any time.
I think the marginal security from using mlock
is not worth the added complexity. So this is resolved to my satisfaction.
If the memory page holding Mosh's session key is swapped to disk, a copy of that key could persist indefinitely. Here's an attack scenario where this matters.
mosh-client
is swapped out to disk.Using POSIX
mlock
, we can prevent this data from being swapped out. But there are some reasons why we might not bother.mlock
does nothing to protect suspended data.Having established that the benefits of
mlock
are real but limited, what are the drawbacks?mlock
is available on Linux and OS X, it is not required on every POSIX platform, as it's part of the Realtime Extension.RLIMIT_MEMLOCK
. This wil be (mis)configured to 0 on some systems, breaking Mosh.From a cursory search, neither OpenSSH nor OpenSSL prevents swapping of cryptographic materials (which is surprising, because unlike Mosh they also handle persistent keys). By contrast, GnuPG includes a custom secure allocator with knowledge of many Unixes.
Perhaps the right solution is to call
mlock
if it is available, and treat failure as a non-fatal condition. But I'm still worried about increased code complexity, versus the limited enhancement to security. Maybe I should just write the code and see how complex it is.Thoughts?