nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-06-30 19:12:48 -05:00
Code Issues Projects Releases Wiki Activity

Implement this year's consensus on CHANNEL_FAILURE vs CHANNEL_CLOSE.

Browse Source 
We now expect that after the server has sent us CHANNEL_CLOSE, we
should not expect to see any replies to our outstanding channel
requests, and conversely after we have sent CHANNEL_CLOSE we avoid
sending any reply to channel requests from the server. This was the
consensus among implementors discussing the problem on ietf-ssh in
April 2014.

To cope with current OpenSSH's (and perhaps other servers we don't
know about yet) willingness to send request replies after
CHANNEL_CLOSE, I introduce a bug-compatibility flag which is detected
for every OpenSSH version up to and including the current 6.6 - but
not beyond, since https://bugzilla.mindrot.org/show_bug.cgi?id=1818
promises that 6.7 will also implement the new consensus behaviour.

[originally from svn r10200]
This commit is contained in:
Simon Tatham
2014-07-06 14:05:39 +00:00
parent 3d337b49ef
commit aaaf70a0fc
6 changed files with 78 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
doc/config.but
View File

@ -3294,6 +3294,31 @@ believes the server has this bug, it will never send its
\cq{winadj@putty.projects.tartarus.org} request, and will make do
without its timing data.
\S{config-ssh-bug-chanreq} \q{Replies to channel requests after channel close}
\cfg{winhelp-topic}{ssh.bugs.chanreq}
The SSH protocol as published in RFC 4254 has an ambiguity which
arises if one side of a connection tries to close a channel, while the
other side simultaneously sends a request within the channel and asks
for a reply. RFC 4254 leaves it unclear whether the closing side
should reply to the channel request after having announced its
intention to close the channel.
Discussion on the \cw{ietf-ssh} mailing list in April 2014 formed a
clear consensus that the right answer is no. However, because of the
ambiguity in the specification, some SSH servers have implemented the
other policy; for example,
\W{https://bugzilla.mindrot.org/show_bug.cgi?id=1818}{OpenSSH used to}
until it was fixed.
Because PuTTY sends channel requests with the \q{want reply} flag
throughout channels' lifetime (see \k{config-ssh-bug-winadj}), it's
possible that when connecting to such a server it might receive a
reply to a request after it thinks the channel has entirely closed,
and terminate with an error along the lines of \q{Received
\cw{SSH2_MSG_CHANNEL_FAILURE} for nonexistent channel 256}.
\H{config-serial} The Serial panel
The \i{Serial} panel allows you to configure options that only apply