Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
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:
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.