nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-25 01:02:24 +00:00
Code Issues Projects Releases Wiki Activity

Split discussion of diabling rekeys between time-based and data-based, since

Browse Source 
disabling the former is much more useful, and much safer, than disabling the
latter.  The new wording on data-based rekeys might need some polishing.

[originally from svn r5222]
This commit is contained in:
Ben Harris 2005-01-28 13:47:37 +00:00
parent 871fb84047
commit e12b2dcb71
1 changed files with 21 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
doc/config.but
View File

@ -2205,6 +2205,20 @@ allowed to elapse before a rekey is initiated. If this is set to zero,
PuTTY will not rekey due to elapsed time. The SSH-2 protocol PuTTY will not rekey due to elapsed time. The SSH-2 protocol
specification recommends a timeout of at most 60 minutes. specification recommends a timeout of at most 60 minutes.
You might have a need to disable time-based rekeys completely for the same
reasons that keepalives aren't always helpful. If you anticipate
suffering a network dropout of several hours in the middle of an SSH
connection, but were not actually planning to send \e{data} down
that connection during those hours, then an attempted rekey in the
middle of the dropout will probably cause the connection to be
abandoned, whereas if rekeys are disabled then the connection should
in principle survive (in the absence of interfering firewalls). See
\k{config-keepalive} for more discussion of these issues; for these
purposes, rekeys have much the same properties as keepalives.
(Except that rekeys have cryptographic value in themselves, so you
should bear that in mind when deciding whether to turn them off.)
Note, however, the the SSH \e{server} can still initiate rekeys.
\b \q{Max data before rekey} specifies the amount of data (in bytes) \b \q{Max data before rekey} specifies the amount of data (in bytes)
that is permitted to flow in either direction before a rekey is that is permitted to flow in either direction before a rekey is
initiated. If this is set to zero, PuTTY will not rekey due to initiated. If this is set to zero, PuTTY will not rekey due to
@ -2224,22 +2238,13 @@ used:
} }
PuTTY can be prevented from initiating a rekey entirely by setting Disabling data-based rekeys entirely is a bad idea. The integrity,
both of these values to zero. (Note, however, that the SSH and to a lesser extent, confidentiality of the SSH-2 protocol depend
\e{server} may still initiate rekeys.) in part on rekeys occuring before a 32-bit packet sequence number
wraps around. Unlike time-based rekeys, data-based rekeys won't occur
You might have a need to disable rekeys completely for the same when the SSH connection is idle, so they shouldn't cause the same
reasons that keepalives aren't always helpful. If you anticipate problems. The SSH-1 protocol, incidentally, has even weaker integrity
suffering a network dropout of several hours in the middle of an SSH protection than SSH-2 without rekeys.
connection, but were not actually planning to send \e{data} down
that connection during those hours, then an attempted rekey in the
middle of the dropout will probably cause the connection to be
abandoned, whereas if rekeys are disabled then the connection should
in principle survive (in the absence of interfering firewalls). See
\k{config-keepalive} for more discussion of these issues; for these
purposes, rekeys have much the same properties as keepalives.
(Except that rekeys have cryptographic value in themselves, so you
should bear that in mind when deciding whether to turn them off.)
\H{config-ssh-auth} The Auth panel \H{config-ssh-auth} The Auth panel