On Sep 12, 2008, at 3:12 PM, Philip Guenther wrote:
On Fri, Sep 12, 2008 at 2:05 PM, johan beisser <[EMAIL PROTECTED]> wrote:
This about security. Being realistic means *not* being optimistic
that extracting data will be "too hard", "too unlikely", "only
applicable to a subset of people [and certainly not me]", etc. Have
you not read enough papers that start with something like "It was
previously thought that attack [foo] was impractical for the following
reasons: [blah blah blah]. This paper demonstrates practical
circumstances under which those reasons fail or don't apply and the
attack succeeds"?
Sure, against SSH1.
http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis/
The ACM paper was also published in 2001, same time frame. There's
more padding (see the TCPDump output I provided) in SSH2. Also, take a
look at what Damien Miller responded with: OpenSSH is applying extra
padding.
SSH2 is the default these days. I won't say it's impossible to do
keystroke analysis, it's just going to be difficult to know if what
two letters were typed and when. Frankly, I've given you ssh2 packet
dump (i'll happily provide raw tcpdump output, if you want it).
As such, statements of "can't be done" that don't have hard data or
proofs attached are pretty much worth the electrons they were sent
with. You might not see how the published attack can be made
practical against you, but someone else will almost certainly see the
next link in making it so. The original posters didn't sound like
they were being overly sensationalist, just interested in cutting off
a possible avenue of attack *before* it becomes a problem.
I'm not a mathematician, let alone a cryptographer. I don't have
access to the latter, but I do to the former with a fair amount of
ease. If you really want a proof.. look at the SSH2 protocol code
yourself. The protocol is open, documented, and so far hasn't been
proven vulnerable to the same analysis SSH1 was. Let alone the key
interception problem in SSH1.
They're different types of attacks; they have different applicability.
Perhaps the timing attack can be done remotely, over a long period of
time, and therefore has a much lower risk of detection. Even better,
it may be possible to do it 'in bulk', where shoulder-surfing and
similar is much harder to parallelize.
If someone can intercept gigabytes of interactive traffic, they're
likely to get keys first, then decrypt session information after that.
If you get enough traffic, you can do pattern analysis for keystrokes
and output (oh, this is output from uh.. "ls -al" I think..), or you
can do traffic analysis to recover the session keys, and possibly
infer the host keys (egads, i hope not). Again, you'll need a fair
amount of horsepower to do it.
I just do not see keystroke analysis as a viable method of attack, let
alone a likely one.
Again, if you're worried about keystroke traffic analysis, pump random
keystrokes through the same ssh tunnel. Multiplex the session and
force a background session to use the same ssh tunnel and execute
arbitrary remote commands interactively.
It doesn't take much to throw off this kind of analysis.
