PuTTY wish zlib-openssh

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

summary: Support for "zlib@openssh.com"
class: wish: This is a request for an enhancement.
difficulty: tricky: Needs many tuits.
priority: medium: This should be fixed one day.
fixed-in: r9120 2011-03-05 (0.61) (0.62) (0.63) (0.64)

OpenSSH 4.2 introduces a variety of ZLIB compression called "zlib@openssh.com" which delays starting compression until after the server has sent SSH_MSG_USERAUTH_ACCEPT. It's configured to use only this by default (or with the "Compression delayed" option in sshd_config), which means that PuTTY cannot negotiate compression; ordinary "zlib" compression can be reinstated with "Compression yes".

The new method is specified in draft-miller-secsh-compression-delayed, currently -00.

As far as we can tell, this is inherently subject to a race condition, since the client can't know whether the server has sent that message, and hence whether it should be transmitting compressed or uncompressed packets. After the client has received USERAUTH_ACCEPT, of course, it knows that the server has sent it and can safely send compressed packets. This suggests that the following implementation would be safe (assuming throughout that the user has requested compression):

Before USERAUTH_ACCEPT is received, advertise "zlib,none" in KEXINIT.
If an incoming KEXINIT includes "zlib@openssh.com", remember that.
After receiving USERAUTH_ACCEPT, if the current compression algorithm is "none" and KEXINIT contained "zlib@openssh.com", initiate key re-exchange.
In KEXINITs after receiving USERAUTH_ACCEPT, advertise "zlib,zlib@openssh.com,none".

There's no need for PuTTY to stop supporting "zlib", since by the time we send NEWKEYS, we've authenticated the server.

Update, 2011-03-05: this is now supported, using the method described above.

Audit trail for this wish.

If you want to comment on this web site, see the Feedback page.
(last revision of this bug record was at 2011-03-04 22:34:47 +0000)