cooked mode sessions

["Howard Chu" <hyc%highlandsun.com@localhost>]

I saw a brief mention of this in the August mail archive, but apparently the
idea was
discarded: I'd like to see support for client-side input processing, to
eliminate
the single-character echoing roundtrips that interactive sessions currently
have.
This should be similar to the Telnet LINEMODE option. For the majority of
terminal
sessions operating a command-line, there's no reason the client can't do all
the
input editing and just send complete lines to the server. This kind of
feature will
improve performance on slow links, and can also lessen the effectiveness of
traffic-
analysis attacks on a session by eliminating keystroke-timing information.

I also saw a Bubble Babble document in the archive, for encoding binary
strings as
English-readable strings. This kind of feature was present in the S/Key
one-time-password system, and also proved to be a vulnerability. If the
characters are typed
one at a time, the language space is so limited that an eavesdropper can
guess the
remainder of the password before the user finishes typing it in. The session
can then be hijacked without needing the user to complete a login. These
vulnerabilities existed with an S/Key login over a cleartext session, so the
situation is different in ssh.
However, it's still important to be aware of potential dangers. Even though
the
initial ssh password can be sent in a single packet, no such protection
exists for
any chained sessions. (E.g., user starts ssh session to machine 1. On
machine 1, user starts ssh session to machine 2. If the user must type a
password for machine 2, it
will be transmitted one character at a time through the machine 1 session.)

Adding support for client-side input editing is a win, for both performance
and
security reasons.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc