Warning message at password prompt

[Frank Cusack]

On Fri, Feb 15, 2002 at 02:31:35PM +0000, Edward Avis wrote:
> On Fri, 15 Feb 2002, Frank Cusack wrote:
> 
> [patching to enable cipher 'none']
> 
> >You need 'none2' otherwise you can't do a 'none' encryption with
> >protocol 2.  (In the openssh implementation, "keywords" for encryption types
> >cannot be shared for protocol 1/2.)
> 
> Actually that is just what I did in my patch, with this change to
> cipher.c:
> 
> - -	if (c == NULL || c->number != SSH_CIPHER_SSH2) {
> +	/* SSH_CIPHER_NONE can be used by both protocol 1 and 2 */
> +	if (c == NULL || (c->number != SSH_CIPHER_SSH2
> +			  && c->number != SSH_CIPHER_NONE)) {
> 
> Since none_setkey() and friends seem to fit both the protocol 1 and
> protocol 2 interface, it seemed best to have the single cipher name
> 'none' in both cases.

I had the same thing originally but opted for 'none2' in the end.
I don't remember why, maybe it was a bad choice after all.

> (In fact, I'd say that cipher names _should_ be shared between
> protocols, with the lookup being done based on name and protocol
> version.  Then 'ssh -1 -c 3des' and 'ssh -2 -c 3des' would use the
> current 3des and 3des-cbc respectively, without the user having to
> memorize those names.  But for my own use I implemented this only for
> 'none'.)

They do.  'ssh -1 -c 3des' and 'ssh -2 -c 3des' both work as the user
expects.

> >--- openssh.orig/sshconnect2.c
> >+++ openssh/sshconnect2.c
> >@@ -449,6 +449,9 @@
> > 	if(attempt != 1)
> > 		error("Permission denied, please try again.");
> >
> >+	if (!strcmp("none2", options.ciphers))
> >+		log("WARNING: Encryption is disabled! "
> >+		    "Response will be transmitted in clear text.");
> 
> Are you sure that is correct?  It tests the options given when invoking
> ssh (or in a config file), but that's not necessarily the same as the
> actual cipher that was negotiated.  Or maybe it is in the current
> implementation, but should sshconnect2.c know that?

I'm not sure it is correct.  I merely "followed along" with what the ssh1
case already did.

> I'm just a bit unhappy with trying to figure out the cipher in use by
> looking at the options struct.  Surely there is a way to get the
> definitive answer of what cipher is being _used_.

Yeah, but it can change at any time, even during the password exchange.
Although, no implementation is likely to actually do this.

> OTOH, I see now that the password-warning code for SSH1 protocol does
> the same thing, looking at the options rather than finding the answer
> directly, so maybe it is acceptable.  This will break if at some future
> date the options specify a list of ciphers, only one of which is used
> after negotiating with the server.

yep.  darn.  So a better patch is probably in order.  I had never even
considered that the warning was based on requested cipher vs used cipher.
With ssh1 this is not an issue.  In real life though, this shouldn't
be an issue; you should never "down-negotiate" to 'none' encryption.

> Another interesting question: is it worthwhile giving a similar warning
> if plain DES is used?  Do we think that password-sniffing by breaking

Already done.

/fc