belated heads-up: changing default SunSSH cipher list (fwd)

belated heads-up: changing default SunSSH cipher list (fwd)

Date: Thu, 22 Jan 2009 16:31:48 +0100 (CET)
From: Jan Pechanec <Jan.Pechanec at sun dot com>
To: onnv-gate at onnv dot eng dot sun dot com, on-all at eng dot sun dot com
Subject: belated heads-up: changing default SunSSH cipher list (fwd)

	resending to correct addresses. My apology to those who get it
multiple times. J.

~--
Jan Pechanec

~---------- Forwarded message ~----------
Date: Thu, 22 Jan 2009 15:18:09 +0100 (CET)
From: Jan Pechanec <Jan.Pechanec at Sun dot COM>
To: nv-users at sun dot com
Subject: belated heads-up: changing default SunSSH cipher list

	hi,

	if you use or are going to use snv_106 or later with SunSSH, whether
as the client or as the server, please read the 1st part of this message.

	after the fix for "6761890 ssh protocol security vulnerability may
be used to reveal some plaintext" where we removed CBC modes from the
_default_ cipher list on both the server and the client side, we found out
that such a new configuration can't connect to S9 servers and servers
upgraded from S9. The symptom is like this:

$ ssh my-s9-machine
no matching cipher found: client aes128-ctr,arcfour,aes192-ctr,aes256-ctr
server aes128-cbc,blowfish-cbc,3des-cbc

	the best fix is to remove Ciphers option on the _server_ side
completely from the /etc/ssh/sshd_config file and make SSH server to re-read
it. On S10 and Nevada, use "svcadm restart svc:/network/ssh:default". On S9
systems, run "/etc/rc3.d/S89sshd restart". You must be root to do that.

	you can use "ssh -o Ciphers=aes128-cbc <machine-name>" to
temporarily override your client side configuration.

	however, the above fix will not work for SunSSH_1.0 shipped with S9
FCS since that doesn't support CTR modes nor arcfour. Note that such version
have security bugs and by patching it you get SunSSH_1.1 (that's what S10
uses) which supports more cipher modes. If you don't want to patch, change
your SSH configuration in .ssh/config. I suggest to use Host directive for
such hosts. For example:

Host my-old-s9*
	Ciphers	aes128-cbc

	some information on S9 SSH patches can be found here:

http://www.opensolaris.org/os/community/security/projects/SSH/#patches

	we understand that the change brought by 6761890 may cause
interoperability problems but this is a trade-off since we are fixing a
security bug. 6778926 will bring an updated SSH man pages with update
Ciphers sections in ssh_config(4) and sshd_config(4).

<first part ends here>

	if you are interested about the history of the problem, read on. The
problem is that S9 was shipped with a default Ciphers settings
"aes128-cbc,blowfish-cbc,3des-cbc" explicitly set in /etc/ssh/sshd_config.
It wasn't a good decision because any later change in the default cipher
list won't take affect automatically. What's more, we think that changing an
already existing Ciphers options in a patch is not a correct thing since
even if it was the exact old default value, it might be something that a
customer want and would complain if we changed his/her configuration.

	a new CR 6787069 was filed which will bring a better message. It
will be probably like this:

	Client and server could not agree on a common cipher:
	  client: aes128-ctr,arcfour,aes192-ctr,aes256-ctr
	  server: aes128-cbc,blowfish-cbc,3des-cbc

	The client ciphers can be controlled using the "Ciphers" option, see
	ssh_config(4) for more information. The "-o Ciphers=<cipher-list>"
	option may be used to temporarily override the ciphers the client
	offers. Note that using non-default ciphers might affect your security."

	similar message will be on the server side, just shorter since it
goes to syslogd and it's important not to introduce line breaks there:

Client and server could not agree on a common cipher: client
aes128-ctr,arcfour,aes192-ctr,aes256-ctr, server
aes128-cbc,blowfish-cbc,3des-cbc. The server ciphers can be controlled using
the "Ciphers" option, see sshd_config(4) for more information."

	J.

~--
Jan Pechanec