[rfe] sshd ought to support 'none' cipher

[Allison Karlitskaya]

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.

[Joey Hess (joey-kite)]

Rob Browning wrote:
>
> Package: ssh
> Version: 1.2.20-3
> Severity: wishlist
>
> I'd like to be able to specify "-c none" (as per the manpage) when I'm
> on a known secure network (like when I'm at home) so that I don't
> incur the encryption overhead when I have no use for it.
>
> I could use telnet or rlogin in those cases, but I'd prefer to
> continue to use ssh so that I can always use the same interface, and
> can will still have the advantages of automatic .Xauthority handling,
> etc.

I'd like to be able to do this too.

--
see shy jo

[Philip Hands (phil-hands)]

> Rob Browning wrote:
> >
> > Package: ssh
> > Version: 1.2.20-3
> > Severity: wishlist
> >
> > I'd like to be able to specify "-c none" (as per the manpage) when I'm
> > on a known secure network (like when I'm at home) so that I don't
> > incur the encryption overhead when I have no use for it.
> >
> > I could use telnet or rlogin in those cases, but I'd prefer to
> > continue to use ssh so that I can always use the same interface, and
> > can will still have the advantages of automatic .Xauthority handling,
> > etc.
>
> I'd like to be able to do this too.

I don't think it should be distributed with this capability.

The description from /usr/doc/ssh/README.CIPHERS makes it fairly clear that this is a bad idea, and since blowfish runs at about 88% of none's speed, you will normally not notice the difference.

Of course, if you want to do this for yourself, you just need to specify --with-none to configure.

Feel free to persuade me otherwise.

Cheers, Phil.

[Rob Browning (rlb-cs)]

Philip Hands <email address hidden> writes:

> The description from /usr/doc/ssh/README.CIPHERS makes it fairly
> clear that this is a bad idea, and since blowfish runs at about 88%
> of none's speed, you will normally not notice the difference.

OK, I hadn't read that. And assuming that idea is the default, I can
probably switch to blowfish and be reasonably happy.

> Of course, if you want to do this for yourself, you just need to
> specify --with-none to configure. Feel free to persuade me
> otherwise.

I feel this falls in the "user choice" arena. As long as "none" is
not the default, and you have to do something to explicitly ask for
it, it's fine. Preventing the user from using "-c none", to me, would
be similar to removing the --force options from dpkg, or the -f option
from e2fsck. I admit that these aren't perfect analogies, but they at
least convey the domain under which I feel this issue falls.

Thanks

--
Rob Browning <email address hidden>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30

[Ben Harris (bjh21)]

merge 13389 24559
thanks

--
Ben Harris
Unix Support, University of Cambridge Computing Service.

[Philip Hands (phil-hands)]

reassign 25075 ssh-nonfree
close 26658
close 40020
merge 13389 24559 52671
close 59306

[Michael Stone (mstone)]

severity wontfix
done

The answer is basically no. There's no simple way in the protocol to
tell whether or not the client or server are actually allowing none
encryption. (Allowed encryption types are represented by a bitmask,
SSH_CRYPT_NONE is 0.)

FWIW, I was interested in doing this myself until I actually dug into
the code. With enough special cases, you might be able to get it
working, but the result would not be pretty; upstream is openly hostile to
the idea of supporting the none encryption option.

--
Mike Stone

[Philip Hands (phil-uk)]

tags 77361 potato
tags 13389 wontfix
tags 24559 wontfix
tags 52671 wontfix

[Brian Ristuccia (brian-ristuccia)]

For applications where encryption is unneeded, undesired, or even
prohibited, but session integrity is absolutely required, it would be useful
to allow version 2 connect with MAC but without a cipher.

(Unfortunately, this looks to be fairly difficult as the SSH_CRYPT_NONE
protocol has been assigned a constant which makes negotiation not so much
fun)...

--
Brian Ristuccia
<email address hidden>
<email address hidden>

[Jari Lammi (jmmlammi)]

Hi,

I'd rather close my telnet port on the machine, which is both on the
amprnet and Internet. However cannot do that while ssh encryption is
always forced.

The "-c none" would definitely be useful. The encryption is prohibited on
amateur radio transmissions, but at our bandwidths (starting from 1200
bps) the ssh compression would be really nice.

Of course, it would be sufficient just to allow the none only for the 44/8
(ampr.org) network. There aren't any non-hamradio related 44.x.x.x
IP-addresses.

Jari Lammi <email address hidden>

[dean gaudet (dean-debian)]

personally i believe it's my own choice whether to enable -c none or not.
with this patch, and the default /etc/ssh/sshd_config, none is disabled.
however if you place an appropriate Ciphers entry into sshd_config then
the none method is enabled.

for example:

Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr,none

-dean

diff -ru openssh-3.8.1p1/cipher.c openssh-3.8.1p1.dg1/cipher.c
--- openssh-3.8.1p1/cipher.c 2004-02-06 17:29:39.000000000 -0800
+++ openssh-3.8.1p1.dg1/cipher.c 2004-10-18 00:48:21.000000000 -0700
@@ -175,7 +175,7 @@
  for ((p = strsep(&cp, CIPHER_SEP)); p && *p != '\0';
      (p = strsep(&cp, CIPHER_SEP))) {
   c = cipher_by_name(p);
- if (c == NULL || c->number != SSH_CIPHER_SSH2) {
+ if (c == NULL || (c->number != SSH_CIPHER_SSH2 && c->number != SSH_CIPHER_NONE)) {
    debug("bad cipher %s [%s]", p, names);
    xfree(ciphers);
    return 0;
@@ -343,6 +343,7 @@
  int evplen;

  switch (c->number) {
+ case SSH_CIPHER_NONE:
  case SSH_CIPHER_SSH2:
  case SSH_CIPHER_DES:
  case SSH_CIPHER_BLOWFISH:
@@ -377,6 +378,7 @@
  int evplen = 0;

  switch (c->number) {
+ case SSH_CIPHER_NONE:
  case SSH_CIPHER_SSH2:
  case SSH_CIPHER_DES:
  case SSH_CIPHER_BLOWFISH:

[Paul Slootman (paul-debian)]

See http://www.psc.edu/networking/projects/hpn-ssh/ for discussions
about improving ssh's performance, including a none cipher.

Paul Slootman

[Allison Karlitskaya (desrt)]

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.

[Colin Watson (cjwatson)]

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.

[Allison Karlitskaya (desrt)]

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.
>

[Colin Watson (cjwatson)]

Rejecting bogus task.

[Colin Watson (cjwatson)]

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.

[Colin Watson (cjwatson)]

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

[Ryan C. Underwood (nemesis-icequake)]

retitle 13389 ssh: Provide HPN-SSH patch for none cipher and variable buffers
tags +patch
thanks

--
Ryan Underwood, <email address hidden>

[Daniel J Blueman (danielblueman)]

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

[Daniel J Blueman (danielblueman)]

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?

[fusiondog (fusiondog)]

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.

[Jonathan Marsden (jmarsden)]

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.

[Alexey Maximov (amax)]

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

[cowmix (mmarch-gmail)]

Is there any chance this might hit 11.10?

[Colin Watson (cjwatson)]

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

[Wyatt Ward (legend5459)]

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

[Alex Lee (alee-x)]

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