PuTTY bug ssh2-kex-data

This is a mirror. The primary PuTTY web site can be found here.

summary: Data transfer during SSH-2 KEX causes confusion
class: bug: This is clearly an actual problem we want fixed.
difficulty: tricky: Needs many tuits.
blocks: ssh2-kex-repeat
priority: medium: This should be fixed one day.
fixed-in: 2004-11-25 (0.58) (0.59) (0.60)

If there is data being transferred through PuTTY while the SSH-2 repeat key exchange is taking place, it can confuse some servers.

In the current SSH-2 protocol drafts, it's not entirely clear to all readers what happens to the connection layer while the transport layer is in a key exchange phase, so it isn't clear from there what PuTTY should do in this situation. A good conservative/liberal option would be to accept incoming connection-layer packets provided we can decrypt them, and to queue outgoing connection-layer packets until the key exchange is completed. I can't easily imagine a standards decision that would invalidate that behaviour.

There has been (repeated) discussion of this issue on IETF SECSH:

Thread 'Key Re-Exchange' starting 4 Apr 2001
Thread 'Some questions about "SSH Transport Layer Encryption Modes"' starting 16 Oct 2003
Thread 'data during rekey?' starting 1 Dec 2003
Thread 'Data transfer during key re-exchange' starting 25 Jun 2004

The consensus seems have settled on the proposal above, and having any nonblocking rekey as a protocol extension (see for instance message <200310192351.h9JNpxAx004282@thunk.east.sun.com>), so we don't now have much excuse for not implementing that; but as of version -18 of the transport draft no change has been made to the actual documents. (See the current version of a proposed change to the language to make this clearer.)

People have also muttered about the receiving end continuing to accept data encrypted using the "old" context; perhaps we'd want to keep an eye on how much data the other end tried to encrypt with a given context and close the connection if in our opinion it was too much. (Although this would be rather rude if we didn't request a rekey first in plenty of time.)

Symptoms of this: ssh.com's server, which does repeat key exchange every hour or so, will sometimes throw you off - a common disconnect message seems to be "Protocol error: Received 94 as newkeys". (We've also had a report of "packet too long" from F-Secure.) This will seem intermittent.

There aren't any really satisfactory workarounds - either using SSH-1 or disabling key re-exchange will both work, but have obvious drawbacks.

Update: should be fixed as of the 2004-11-25 snapshot. We haven't been able to test it very thoroughly yet, though, so testing is welcomed.

Audit trail for this bug.

If you want to comment on this web site, see the Feedback page.
(last revision of this bug record was at 2005-03-10 16:36:42 +0000)