[rfe] sshd ought to support 'none' cipher

Binary package hint: ssh

Please enable the 'none' cipher on sshd.

This will prevent people from having to recompile their sshd to enable it.

The none cipher is only used if the client explicitly requests it. Furthermore, the admin has the option of disabling it entirely via the 'Ciphers' parameter of the /etc/ssh/sshd_config file. The shipped sshd_config file could even disable it as per default.

With the ability to have this option configurable via a config file it seems a bit heavy-fisted to disable it at compile-time.

I am very unconvinced about this (none implies that *authentication* happens in plaintext, as far as I know!). I recommend that people wanting performance use the blowfish-cbc cipher.

Doing password authentication over 'none' cipher is indeed quite bad
(unless you're on a trusted local network) but RSA/DSA authentication
over an unencrypted transport is totally secure in that no key
information is leaked and it's not possible to authenticate without a
proper key.

Of course, you are more open to session hijacking, but that sort of goes
without saying.

On Wed, 2006-26-07 at 17:02 +0000, Colin Watson wrote:
> I am very unconvinced about this (none implies that *authentication*
> happens in plaintext, as far as I know!). I recommend that people
> wanting performance use the blowfish-cbc cipher.
>

Rejecting bogus task.

For what it's worth, despite claims I've heard to the contrary, this is not something that has been intentionally disabled versus upstream by the Debian/Ubuntu packaging, it's not a configure option, and it's not a trivial one-line change. At minimum, I'd want to disable password authentication when using the none cipher (there's at least one patch out there that hacks in "none" by abusing constants that are there for SSH1, and that doesn't attempt to do this), and it would be absolutely necessary to confirm that downgrade attacks such as http://www.security-express.com/archives/bugtraq/1999-q4/0318.html aren't possible.

The best approach I've seen so far to this is that done by http://www.psc.edu/networking/projects/hpn-ssh/ (http://www.psc.edu/networking/projects/hpn-ssh/none.php describes their approach), since that rekeys to the none cipher after authentication and disables it if a tty is requested. That said, having looked at that patch, I'm not happy integrating the HPN bits unless and until they go upstream. I may consider the NoneEnabled/NoneSwitch parts of it, although they'll need a very careful code review.

(Claims that this is a configure option date from SSH1; this option was removed by upstream a long time ago.)

Problem is that SSH performance is still 10-30x slower with encryption. On a 3.6GHz Intel Penryn with plenty of memory bandwidth [1], we see around 67MB/s - 109MB/s [2]. Moving from 'secret' aes-128-cbc (the default) to 'top-secret' aes-256-cbc (the most secure) is almost free.

Moving from MD5 hashing reduces performance too [3].

--- [1]

$ sudo hdparm -T /dev/sda
/dev/sda:
 Timing cached reads: 18030 MB in 2.00 seconds = 9026.75 MB/sec

--- [2]

$ for c in 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr arcfour128 arcfour256 arcfour blowfish-cbc cast128-cbc; do echo using cipher $c; ssh -c $c localhost dd if=/dev/zero bs=32k count=10000 >/dev/null; done

3des-cbc 22.6 MB/s
aes128-cbc 63.8 MB/s
aes192-cbc 67.6 MB/s
aes256-cbc 67.4 MB/s
aes128-ctr 74.9 MB/s
aes192-ctr 73.6 MB/s
aes256-ctr 73.3 MB/s
arcfour128 109 MB/s
arcfour256 108 MB/s
arcfour 107 MB/s
blowfish-cbc 75.0 MB/s
cast128-cbc 62.0 MB/s

--- [3]

$ for m in hmac-md5 hmac-sha1 umac-64 hmac-ripemd160; do echo using digest $m; ssh -c arcfour128 -m $m localhost dd if=/dev/zero bs=32k count=10000 >/dev/null; done

hmac-md5 108 MB/s
hmac-sha1 97.9 MB/s
hmac-ripemd160 83.0 MB/s

This is the 'none' cipher patch:

http://www.psc.edu/networking/projects/hpn-ssh/openssh5.1-dynwindow_noneswitch.diff.gz
(from http://www.psc.edu/networking/projects/hpn-ssh/)

Since security is so critical, perhaps we should defer judgement to the OpenSSH mailing lists?

I find it frustrating when those that don't understand the value of something patently reject it without research. FTP and other protocols make use of kerberos to authenticated securely then transmit the data in plaintext. This should be trivial to do in ssh, especially if using RSA/DSA key methods. I work in linux production datacenters and I know the value of this FEATURE for transferring bulk data over trusted networks or data that need not be secured. OpenSSh is flexible and easy way to perform network streams over my trusted network, but the encryption slows transfer and forces me to find other less secure, more difficult and redundant services to install and maintain. I don't think this should be default behavior but telling me that you reject out of hand that I am competent enough to make my own decisions about how I run services on my network is rather myopic. As far as you know is not far enough.

fusiondog: Could I recommend that you consider doing something positive? If you are willing to work with upstream (that is, with the developers of openssh) to get this option included by default in their released source code, that would make getting it included into future releases of Ubuntu *much* more likely than simply venting your frustrations.

I want to see this in ubuntu 10.04, i need none cipher in my enterprise env. please add "none" patch

Is there any chance this might hit 11.10?

No. My statements in comment #16 stand; this needs to go upstream *first*.

I just want to say that I need this too... Please. It's not that terribly hard.

Hello Folks,

I hate to beat an already "terribly beaten horse" but I'd like to say that I would like the null cipher option to be available. The reason being is that working for a WAN optimization company, the need to "see" the unencrypted traffic is paramount in order to reduce SSH's network footprint. In terms of security, most WAN optimization vendors do provide a "secured transport" (IPSEC or SSL-based tunnels) across the WAN to prevent passwords and app-data from being snooped.

Trust me, I do understand the desire to prevent SSH users from shooting themselves and their company's in the foot, however, having a null cipher option does have value - in the WAN opt case, its a business/network-cost-savings value.

Alex