On Sep 13, 2008, at 3:21 AM, Toni Spets wrote:
What about some known patterns like "screen (-r)" from the start of
every session for example in an IRC shell where most people do that
first? Could it be used with lots of data to crack open future
sessions?
I would say "yes it's possible. But really unlikely."
Here's why, if you look at the algorithm used for transport you'll see
that "screen" will not always show up as the same chunks data+padding.
The negotiated transport encryption should handle blocks of data and
pad it (preferably with random data)[1]. There's no guarantee that the
each TCP packet sent from Adam to Charlie is just a single keypress,
nor is there a guarantee that OpenSSH will prevent the fragmentation
of its transport packet to ease transport through the internet
(smaller MTU, TCP windows expiring, retransmission, etc).
So, Eve will still have to reassemble the TCP stream (easy, if she's
near Adam or Charlie, or on the main ATM link between the two), then
be able to figure out the negotiated transport protocol (harder)[2],
then figure out the negotiated session keys (much harder)[3].
Short of someone screwing up OpenSSL or there being a flaw in OpenSSH,
it's very difficult to attack the encryption directly. There are
exceptions though, especially if the pool of potential host and
session keys is relatively small[4], and you have enough spare CPU
cycles to generate each potential key[5].
I dunno, I find the concern over keystroke timing analysis to be
amusing, but ultimately a waste of worry and concern. As a systems
admin, I'd worry more about badly coded web apps, open ports on the
firewall, and weak passwords on my user accounts. There are greater
fish to fry, and easier avenues of data disclosure.
[1] From the SSH transport protocol RFC (RFC4253):
"Arbitrary-length padding, such that the total length of
(packet_length || padding_length || payload || random padding) is a
multiple of the cipher block size or 8, whichever is larger. There
MUST be at least four bytes of padding. The padding SHOULD consist of
random bytes. The maximum amount of padding is 255 bytes."
[2] Lucky for Eve, this is made easier through the RFC again (section
6.3): all the transport algorithms are listed for her to try and check
for. If Eve doesn't mind exposing herself, or leaving traces she's
around, she can even get a list of what the server supports. Even if
she can't decrypt the data, she's got the advantage in attacking and
trying to recover the session key. The more data she can work with,
the better. If by some chance she can get the servers host keys, she
still has to figure out the session keys; it's just much easier now.
[3] Session keys can be renegotiated periodically/for each gigabyte of
data sent through the link. See section 9 of RFC4253. You can do this
more often, but it's CPU intensive due to the algorithm not being
symmetric. The Diffie-Hellman Key Exchange overview in Section-8 gives
you all the gory details. http://tools.ietf.org/html/rfc4253#section-8
[4] http://en.wikipedia.org/wiki/OpenSSL#Debian_security_breach
[5] http://metasploit.com/users/hdm/tools/debian-openssl/
