nisse%lysator.liu.se@localhost (Niels Möller) writes: > The problem is the interactivity. Let's consider the simplest example > (but I'm not saying this example captures all essentials of the > problem). Say I let my shell connection idle for some time, then I type > a couple of characters, and I want a timely response before I type the > next command. Then my typing has to correspond to a TCP segment that can > be decrypted and authenticated and passed on to the remote shell. With > the current ssh protocol, that TCP segment will carry a single > CHANNEL_DATA packet, possibly in combination with fragments of IGNORE > messages and possibly other piggybacking messages, e.g., WINDOW_ADJUST. > > To hide the user's typing from traffic analysis is a tradeoff, with > varying amounts of cover traffic (preferably including responses; > there's maybe some use for an IGNORE_CONTENTS_BUT_PLEASE_REPLY message > type). In libssh2 there is a keepalive message that can be sent regulary. It is a SSH_MSG_GLOBAL_REQUEST with the want-reply bit set. It should be replied to (typically with a SSH_MSG_REQUEST_FAILURE message). That said, I'm also skeptic whether this is an effort that will pan out. I don't see the problem statement sufficiently strong to motivate work. In general that may be because the idea is too weak, but can also be that the problem statement is not fleshed out well enough. Right now it is hard to tell which case applies, but the end result is the same (=nothing will happen). /Simon
Attachment:
signature.asc
Description: PGP signature