OpenSSH and keystroke timings

[Howard Chu]

Dan Kaminsky wrote:
> Well, there's a lot here.  Lets go down the line.
>
> 1) Password entry only occurs during keyboard-interactive mode, which at
> least isn't used by default (though it may be set on some distros).
> There's no way to downgrade someone as a MITM either.

Password entry is not the only point of vulnerability. Character timing can be 
analyzed continuously, to create a profile of the user generating the input.

> 2) Passwords in general are a terribly flawed technology, made only
> palatable by the disaster that is everything else (yes, this includes
> rsa/dsa in SSH).

Yes, but that's only one specific example of the overall problem.

> 3) Only the most basic of interactions with a server are line based.
> Even something as simple as vi requires full character mode
> interactivity.  Heck, tab completion doesn't even work without it.

Please read the telnet RFCs regarding LINEMODE. Tab completion is still 
supported; the protocol allows "forwarding characters" to be specified on the 
fly. You can have complete local editing when in command-line mode without 
losing any of the conveniences that modern shells provide. Obviously vi still 
requires character-at-a-time mode, but if you're connecting to a distant 
system over a tin-can-and-string network you should know about ex, ed, or 
sed... There's also tn3270, for a model of page-at-a-time full screen editing. 
Again: these are problems that were solved decades ago in the telnet 
specifications. Why not take the few minutes to read them, rather than suffer 
from the same problems over and over again... Interactivity is best handled on 
the local client; forcing people to wait a full packet roundtrip time for 
every byte of data they type is a waste of life.

> 4) The right way to solve this class of problem isn't with LINEMODE tty,
> it's with constant timing / constant bandwidth padding in the underlying
> transport -- or at least, to make changes in timing and bandwidth happen
> a few orders of magnitude slower than the data that's driving them.
> SSH1 and SSH2 as protocols have full support for contentless packets
> that contain only padding; I'd love to see a patch.

"This class of problem" is only a part of the problem. If you "solve" this by 
injecting additional packets/padding, you only make usage over congested high 
latency networks worse. Bandwidth is neither unlimited nor free, and here's 
another truism: congestion, like latency, will only increase over time, it 
will never decrease.

Someday, someone on Earth is going to want to open a secure shell session to a 
machine on the moon, or on Mars, or wherever, or vice versa. You can fix this 
in ssh now, or let people keep reinventing remote login protocols for decades 
to come...

> On Tue, Sep 8, 2009 at 11:44 PM, Howard Chu <hyc at symas.com
> <mailto:hyc at symas.com>> wrote:
>
>     Old news, but ... http://lwn.net/Articles/298833/
>
>     I first posted about this back in 2001 and it's still not resolved:
>     http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html
>
>     1) high latency networks are a reality that will never go away. In
>     fact they will only become more prevalent since distributed networks
>     continue to grow broader but (surprise) the speed of light remains a
>     constant.
>     2) character-at-a-time protocols have both security and performance
>     costs.
>     3) a solution for this has existed in common operating systems for a
>     couple of decades already (LINEMODE tty support).
>
>     It's strange how the secsh group at the IETF refused to learn from
>     the lessons already gained from the years of experience with the
>     telnet protocol.

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