Differences
This shows you the differences between the selected revisions of the page.
| ui_login_bugs 2017-10-19 | ui_login_bugs 2022-06-16 (current) | ||
| Line 1: | Line 1: | ||
| - | ====== Bugs Page (Advanced Site Settings dialog) ====== | + | ====== The Bugs Page (Advanced Site Settings dialog) ====== |
| The //Bugs page// on the [[ui_login_advanced|Advanced Site Settings dialog]] allows you to configure the bugs WinSCP should expect to see in the [[ssh|SSH]] server. | The //Bugs page// on the [[ui_login_advanced|Advanced Site Settings dialog]] allows you to configure the bugs WinSCP should expect to see in the [[ssh|SSH]] server. | ||
| Line 16: | Line 16: | ||
| &toc_title(Refer to documentation of individual bugs:) | &toc_title(Refer to documentation of individual bugs:) | ||
| - | ===== Chokes on SSH-2 ignore messages ===== | + | ===== [[sshbug_ignore2]] Chokes on SSH ignore messages ===== |
| - | An ignore message (''SSH_MSG_IGNORE'') is a message in the SSH protocol which can be sent from the client to the server, or from the server to the client, at any time. Either side is required to ignore the message whenever it receives it. WinSCP uses ignore messages in SSH-2 to confuse the encrypted data stream and make it harder to cryptanalyze. It also uses ignore messages for [[ui_login_connection#keepalives|connection keepalives]]. | + | An ignore message (''SSH_MSG_IGNORE'') is a message in the SSH protocol which can be sent from the client to the server, or from the server to the client, at any time. Either side is required to ignore the message whenever it receives it. WinSCP uses ignore messages in SSH to confuse the encrypted data stream and make it harder to cryptanalyze. It also uses ignore messages for [[ui_login_connection#keepalives|connection keepalives]]. |
| If it believes the server to have this bug, WinSCP will stop using ignore messages. If this bug is enabled when talking to a correct server, the session will succeed, but keepalives will not work and the session might be less cryptographically secure than it could be. | If it believes the server to have this bug, WinSCP will stop using ignore messages. If this bug is enabled when talking to a correct server, the session will succeed, but keepalives will not work and the session might be less cryptographically secure than it could be. | ||
| - | ===== Chokes on WinSCP's SSH-2 'winadj' requests ===== | + | ===== [[sshbug_winadj]] Chokes on WinSCP's SSH 'winadj' requests ===== |
| WinSCP sometimes sends a special request to SSH servers in the middle of channel data, with the name ''winadj@putty.projects.tartarus.org''. The purpose of this request is to measure the round-trip time to the server, which WinSCP uses to tune its flow control. The server does not actually have to understand the message; it is expected to send back a ''SSH_MSG_CHANNEL_FAILURE'' message indicating that it didn't understand it. (All WinSCP needs for its timing calculations is some kind of response.) | WinSCP sometimes sends a special request to SSH servers in the middle of channel data, with the name ''winadj@putty.projects.tartarus.org''. The purpose of this request is to measure the round-trip time to the server, which WinSCP uses to tune its flow control. The server does not actually have to understand the message; it is expected to send back a ''SSH_MSG_CHANNEL_FAILURE'' message indicating that it didn't understand it. (All WinSCP needs for its timing calculations is some kind of response.) | ||
| It has been known for some %%SSH%% servers to get confused by this message in one way or another – because it has a long name, or because they can't cope with unrecognized request names even to the extent of sending back the correct failure response, or because they handle it sensibly but fill up the server's log file with pointless spam, or whatever. WinSCP therefore supports this bug-compatibility flag: if it believes the server has this bug, it will never send its ''winadj@putty.projects.tartarus.org'' request, and will make do without its timing data. | It has been known for some %%SSH%% servers to get confused by this message in one way or another – because it has a long name, or because they can't cope with unrecognized request names even to the extent of sending back the correct failure response, or because they handle it sensibly but fill up the server's log file with pointless spam, or whatever. WinSCP therefore supports this bug-compatibility flag: if it believes the server has this bug, it will never send its ''winadj@putty.projects.tartarus.org'' request, and will make do without its timing data. | ||
| - | ===== [[sshbug_hmac2]] Miscomputes SSH-2 HMAC keys ===== | + | ===== [[sshbug_hmac2]] Miscomputes SSH HMAC keys ===== |
| Versions 2.3.0 and below of the SSH server software from ssh.com compute the keys for their HMAC message authentication codes incorrectly. A typical symptom of this problem is that WinSCP dies unexpectedly at the beginning of the session, saying "Incorrect MAC received on packet". | Versions 2.3.0 and below of the SSH server software from ssh.com compute the keys for their HMAC message authentication codes incorrectly. A typical symptom of this problem is that WinSCP dies unexpectedly at the beginning of the session, saying "Incorrect MAC received on packet". | ||
| Line 33: | Line 33: | ||
| If this bug is detected, WinSCP will compute its HMAC keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail. | If this bug is detected, WinSCP will compute its HMAC keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail. | ||
| - | This is an SSH-2-specific bug. | + | ===== [[sshbug_derivekey2]] Miscomputes SSH encryption keys ===== |
| - | + | ||
| - | ===== [[sshbug_derivekey2]] Miscomputes SSH-2 encryption keys ===== | + | |
| Versions below 2.0.11 of the SSH server software from ssh.com compute the keys for the session encryption incorrectly. This problem can cause various error messages, such as [[message_incoming_packet_was_garbled_on_decryption|"Incoming packet was garbled on decryption"]], or possibly even "Out of memory". | Versions below 2.0.11 of the SSH server software from ssh.com compute the keys for the session encryption incorrectly. This problem can cause various error messages, such as [[message_incoming_packet_was_garbled_on_decryption|"Incoming packet was garbled on decryption"]], or possibly even "Out of memory". | ||
| Line 41: | Line 39: | ||
| If this bug is detected, WinSCP will compute its encryption keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail. | If this bug is detected, WinSCP will compute its encryption keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail. | ||
| - | This is an SSH-2-specific bug. | + | ===== [[sshbug_rsapad2]] Requires padding on SSH RSA signatures ===== |
| - | + | ||
| - | ===== [[sshbug_rsapad2]] Requires padding on SSH-2 RSA signatures ===== | + | |
| - | + | ||
| - | Versions below 3.3 of [[&openssh|OpenSSH]] and versions below 1.3.4d/1.3.5rc4 of ProFTPD/mod_sftp require SSH-2 RSA signatures to be padded with zero bytes to the same length as the %%RSA%% key modulus. The %%SSH-2%% draft specification says that an unpadded signature MUST be accepted, so this is a bug. A typical symptom of this problem is that WinSCP mysteriously fails %%RSA%% authentication once in every few hundred attempts, and falls back to passwords. In session log file you will typically see this record: | + | |
| - | + | ||
| + | Versions below 3.3 of [[&openssh|OpenSSH]] and versions below 1.3.4d/1.3.5rc4 of ProFTPD ''mod_sftp'' require SSH RSA signatures to be padded with zero bytes to the same length as the %%RSA%% key modulus. The %%SSH%% specification says that an unpadded signature MUST be accepted, so this is a bug. A typical symptom of this problem is that WinSCP mysteriously fails %%RSA%% authentication once in every few hundred attempts, and falls back to passwords. In session log file you will typically see this record: | ||
| <code> | <code> | ||
| Line 56: | Line 49: | ||
| If this bug is detected, WinSCP will pad its signatures in the way the buggy servers expect. If this bug is enabled when talking to a correct server, it is likely that no damage will be done, since correct servers usually still accept padded signatures because they're used to talking to OpenSSH. | If this bug is detected, WinSCP will pad its signatures in the way the buggy servers expect. If this bug is enabled when talking to a correct server, it is likely that no damage will be done, since correct servers usually still accept padded signatures because they're used to talking to OpenSSH. | ||
| - | This is an %%SSH-2%%-specific bug. | + | ===== Misuses the session ID in SSH PK auth ===== |
| - | ===== Misuses the session ID in SSH-2 PK auth ===== | + | Versions below 2.3 of [[&openssh|OpenSSH]] require SSH public-key authentication to be done slightly differently: the data to be signed by the client contains the session ID formatted in a different way. If public-key authentication mysteriously does not work but the session log shows that WinSCP has successfully sent a signature, it might be worth enabling the workaround for this bug to see if it helps. |
| - | Versions below 2.3 of [[&openssh|OpenSSH]] require SSH-2 public-key authentication to be done slightly differently: the data to be signed by the client contains the session ID formatted in a different way. If public-key authentication mysteriously does not work but the session log shows that WinSCP has successfully sent a signature, it might be worth enabling the workaround for this bug to see if it helps. | + | If this bug is detected, WinSCP will sign data in the way OpenSSH expects. If this bug is enabled when talking to a correct server, %%SSH%% public-key authentication will fail. |
| - | If this bug is detected, WinSCP will sign data in the way OpenSSH expects. If this bug is enabled when talking to a correct server, %%SSH-2%% public-key authentication will fail. | + | ===== Handles SSH key re-exchange badly ===== |
| - | + | ||
| - | This is an %%SSH-2%%-specific bug. | + | |
| - | + | ||
| - | ===== Handles SSH-2 key re-exchange badly ===== | + | |
| Some SSH servers cannot cope with repeat key exchange at all, and will ignore attempts by the client to start one. Since WinSCP pauses the session while performing a repeat key exchange, the effect of this would be to cause the session to hang after an hour (unless you have your [[ui_login_kex|rekey timeout set differently]]). Other, very old, %%SSH%% servers handle repeat key exchange even more badly, and disconnect upon receiving a repeat key exchange request. | Some SSH servers cannot cope with repeat key exchange at all, and will ignore attempts by the client to start one. Since WinSCP pauses the session while performing a repeat key exchange, the effect of this would be to cause the session to hang after an hour (unless you have your [[ui_login_kex|rekey timeout set differently]]). Other, very old, %%SSH%% servers handle repeat key exchange even more badly, and disconnect upon receiving a repeat key exchange request. | ||
| Line 72: | Line 61: | ||
| If this bug is detected, WinSCP will never initiate a repeat key exchange. If this bug is enabled when talking to a correct server, the session should still function, but may be less secure than you would expect. | If this bug is detected, WinSCP will never initiate a repeat key exchange. If this bug is enabled when talking to a correct server, the session should still function, but may be less secure than you would expect. | ||
| - | This is an SSH-2-specific bug. | + | ===== [[sshbug_maxpkt2]] Ignores SSH maximum packet size ===== |
| - | ===== [[sshbug_maxpkt2]] Ignores SSH-2 maximum packet size ===== | + | When an SSH channel is set up, each end announces the maximum size |
| - | + | ||
| - | When an SSH-2 channel is set up, each end announces the maximum size | + | |
| of data packet that it is willing to receive for that channel. Some | of data packet that it is willing to receive for that channel. Some | ||
| servers ignore WinSCP's announcement and send packets larger than WinSCP | servers ignore WinSCP's announcement and send packets larger than WinSCP | ||
| Line 86: | Line 73: | ||
| correct server, the session will work correctly, but download | correct server, the session will work correctly, but download | ||
| performance will be less than it could be. ((&puttydoccite)) | performance will be less than it could be. ((&puttydoccite)) | ||
| - | |||
| - | ===== [[sshbug_ignore1]] Chokes on SSH-1 ignore messages ===== | ||
| - | An ignore message (SSH_MSG_IGNORE) is a message in the SSH protocol which can be sent from the client to the server, or from the server to the client, at any time. Either side is required to ignore the message whenever it receives it. WinSCP uses ignore messages to hide the password packet in SSH-1, so that a listener cannot tell the length of the user's password; it also uses ignore messages for [[ui_login_connection#keepalives|connection keepalives]]. | ||
| - | |||
| - | If this bug is detected, WinSCP will stop using ignore messages. This means that keepalives will stop working, and WinSCP will have to fall back to a secondary defense against [[#sshbug_plainpw1|SSH-1 password-length eavesdropping]]. If this bug is enabled when talking to a correct server, the session will succeed, but keepalives will not work and the session might be more vulnerable to eavesdroppers than it could be. | ||
| - | |||
| - | This is an %%SSH-1%%-specific bug. No known %%SSH-2%% server fails to deal with %%SSH-2%% ignore messages. | ||
| - | |||
| - | ===== [[sshbug_plainpw1]] Refuses all SSH-1 password camouflage ===== | ||
| - | When talking to an SSH-1 server which cannot deal with [[#sshbug_ignore1|ignore messages]], WinSCP will attempt to disguise the length of the user's password by sending additional padding within the password packet. This is technically a violation of the %%SSH-1%% specification, and so WinSCP will only do it when it cannot use standards-compliant ignore messages as camouflage. In this sense, for a server to refuse to accept a padded password packet is not really a bug, but it does make life inconvenient if the server can also not handle ignore messages. | ||
| - | |||
| - | If this bug is detected, WinSCP will assume that neither ignore messages nor padding are acceptable, and that it thus has no choice but to send the user's password with no form of camouflage, so that an eavesdropping user will be easily able to find out the exact length of the password. If this bug is enabled when talking to a correct server, the session will succeed, but will be more vulnerable to eavesdroppers than it could be. | ||
| - | |||
| - | This is an %%SSH-1%%-specific bug. SSH-2 is secure against this type of attack. | ||
| - | |||
| - | ===== Chokes on SSH-1 RSA authentication ===== | ||
| - | |||
| - | Some SSH-1 servers cannot deal with RSA authentication messages at all. If [[ui_pageant|Pageant]] is running and contains any %%SSH-1%% keys, WinSCP will normally automatically try %%RSA%% authentication before falling back to passwords, so these servers will crash when they see the %%RSA%% attempt. | ||
| - | |||
| - | If this bug is detected, WinSCP will go straight to password authentication. If this bug is enabled when talking to a correct server, the session will succeed, but of course %%RSA%% authentication will be impossible. | ||
| - | |||
| - | This is an %%SSH-1%%-specific bug. | ||
| ===== Further Reading ===== | ===== Further Reading ===== | ||
| Read more about [[ui_login|Login dialog]] and [[ui_login_advanced|Advanced Site Settings dialog]]. | Read more about [[ui_login|Login dialog]] and [[ui_login_advanced|Advanced Site Settings dialog]]. | ||