hyc at symas
Sep 8, 2009, 3:38 PM
Post #3 of 5
(771 views)
Permalink
|
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
> <mailto:hyc [at] symas>> 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/
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|
