Minor semantic tweak to bug-compatibility modes: make

BUG_NEEDS_SSH1_PLAIN_PASSWORD do exactly what it says on the tin, independent
of whether BUG_CHOKES_ON_SSH1_IGNORE is set.

This is invisible in the default configuration, as all servers marked as having
the second bug have the first one too, but it would allow one to manually
configure PuTTY to cope with a SSH-1 server that got upset by ignore messages
during authentication, but was fine with their use as keepalives.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6876 cda61777-01e9-0310-a592-d414129be87e

diff --git a/doc/config.but b/doc/config.but
index ff41891..18c9d9f 100644 (file)
--- a/doc/config.but
+++ b/doc/config.but
@@ -2789,10 +2789,11 @@ to try to guess whether or not the server has the bug.
 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. PuTTY 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
-connection keepalives (see \k{config-keepalive}).
+message whenever it receives it. PuTTY uses ignore messages to
+\I{password camouflage}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 connection \i{keepalives} (see
+\k{config-keepalive}).
 
 If this bug is detected, PuTTY will stop using ignore messages. This
 means that keepalives will stop working, and PuTTY will have to fall
@@ -2819,9 +2820,10 @@ 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 \q{bug} is detected, PuTTY will have 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
+If this \q{bug} is detected, PuTTY 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.

diff --git a/ssh.c b/ssh.c
index 8147485..fc75e91 100644 (file)
--- a/ssh.c
+++ b/ssh.c
@@ -2166,6 +2166,13 @@ static void ssh_detect_bugs(Ssh ssh, char *vstring)
 
     ssh->remote_bugs = 0;
 
+    /*
+     * General notes on server version strings:
+     *  - Not all servers reporting "Cisco-1.25" have all the bugs listed
+     *    here -- in particular, we've heard of one that's perfectly happy
+     *    with SSH1_MSG_IGNOREs -- but this string never seems to change,
+     *    so we can't distinguish them.
+     */
     if (ssh->cfg.sshbug_ignore1 == FORCE_ON ||
        (ssh->cfg.sshbug_ignore1 == AUTO &&
         (!strcmp(imp, "1.2.18") || !strcmp(imp, "1.2.19") ||
@@ -3703,19 +3710,19 @@ static int do_ssh1_login(Ssh ssh, unsigned char *in, int inlen,
             *    magnitude of the password length, but it will
             *    introduce a bit of extra uncertainty.
             * 
-            * A few servers (the old 1.2.18 through 1.2.22)
-            * can't deal with SSH1_MSG_IGNORE. For these
-            * servers, we need an alternative defence. We make
-            * use of the fact that the password is interpreted
-            * as a C string: so we can append a NUL, then some
-            * random data.
+            * A few servers can't deal with SSH1_MSG_IGNORE, at
+            * least in this context. For these servers, we need
+            * an alternative defence. We make use of the fact
+            * that the password is interpreted as a C string:
+            * so we can append a NUL, then some random data.
             * 
-            * One server (a Cisco one) can deal with neither
-            * SSH1_MSG_IGNORE _nor_ a padded password string.
-            * For this server we are left with no defences
+            * A few servers can deal with neither SSH1_MSG_IGNORE
+            * here _nor_ a padded password string.
+            * For these servers we are left with no defences
             * against password length sniffing.
             */
-           if (!(ssh->remote_bugs & BUG_CHOKES_ON_SSH1_IGNORE)) {
+           if (!(ssh->remote_bugs & BUG_CHOKES_ON_SSH1_IGNORE) &&
+               !(ssh->remote_bugs & BUG_NEEDS_SSH1_PLAIN_PASSWORD)) {
                /*
                 * The server can deal with SSH1_MSG_IGNORE, so
                 * we can use the primary defence.
@@ -3784,10 +3791,8 @@ static int do_ssh1_login(Ssh ssh, unsigned char *in, int inlen,
                            PKTT_OTHER, PKT_END);
            } else {
                /*
-                * The server has _both_
-                * BUG_CHOKES_ON_SSH1_IGNORE and
-                * BUG_NEEDS_SSH1_PLAIN_PASSWORD. There is
-                * therefore nothing we can do.
+                * The server is believed unable to cope with
+                * any of our password camouflage methods.
                 */
                int len;
                len = strlen(s->cur_prompt->prompts[0]->result);