Subject: cooked mode sessions

From: "Howard Chu" <[email-masked]>
Date: Sun, 2 Sep 2001 13:36:49 -0700

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

---

From: [email-masked] (Sami J. Lehtinen)
Date: 03 Sep 2001 04:00:53 +0300

[email-masked] ("Howard Chu") writes:

> I'd like to see support for client-side input processing, to
> eliminate

Why can't this be done with the current protocol spec?

> remainder of the password before the user finishes typing it in. 

Bubble Babble is intended (and currently only used) as an encoding
style for fingerprints. So the situation you describe does not apply.

Cheers,
-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: "Howard Chu" <[email-masked]>
Date: Sun, 2 Sep 2001 20:31:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Sami J. Lehtinen

> Why can't this be done with the current protocol spec?

Some kind of message is needed to tell the client about pty mode changes.
E.g., if
the app issues an ioctl to turn echo off, a protocol message is needed to
convey this state change. All of the terminal-mode settings that a client
sends in its "pty-req"
could potentially be sent from the server to the client at any time. There
are many
other instances where such a message is needed.