Mailing List Archive: [Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none"

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none"

bugzilla-daemon at mindrot

Jun 5, 2004, 3:40 PM

Post #1 of 49 (902 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

Summary: ssh 3.8.1p1 client cannot disable encryption with "-c
none"
Product: Portable OpenSSH
Version: 3.8.1p1
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: ssh
AssignedTo: openssh-bugs@mindrot.org
ReportedBy: mohit_aron@hotmail.com

I'm using an ssh 3.8.1p1 client on my home machine to connect to my an sshd
3.6.1p2 server on my office machine. Since I'm connecting over a VPN connection,
I have no need for encryption. However, since my office machine does not run
telnet/rlogin server, I can only connect to it using ssh. Thus, I need to turn off
encryption while connecting. It seems I'm not able to do this with the '-c none'
option. Here's the error I get when I run 'ssh -c none' to my office machine:
No valid ciphers for protocol version 2 given, using defaults.

The /etc/ssh/sshd_config file on my office machine does contain the following
line:
Ciphers aes128-cbc,blowfish-cbc,3des-cbc,cast128-cbc,none2

However, the ssh 3.8.1p1 client doesn't seem to recognize the cipher 'none2'.
This is confirmed by looking at the openssh source in the file cipher.c.
There is no cipher called "none2" in 3.8.1p1 source while it exists in
3.6.1p2 source.

So I guess there are two problems:
(1) ssh 3.8.1p1 client isn't able to disable encryption when talking to
a 3.6.1p2 sshd which allows the none2 cipher.
(2) The man page for ssh 3.8.1p1 doesn't indicate an option '-c none'
while the man page for ssh 3.6.1p2 does. I hope the ability to
open an unencrypted ssh channel hasn't been removed by the developers
in the later version of ssh.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 5, 2004, 6:22 PM

Post #2 of 49 (902 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

dtucker@zip.com.au changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|ssh 3.8.1p1 client cannot |ssh 3.8.1p1 client cannot
|disable encryption with "-c |disable encryption with "-c
|none" |none"

------- Additional Comments From dtucker@zip.com.au 2004-06-06 12:22 -------
There is no "none2" cipher in 3.6.1p2, perhaps it was added by your vendor?

$ cd openssh-cvs
$ cvs up -dP -r V_3_6_1_P2
$ grep none2 *
$

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 8:08 AM

Post #3 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-07 02:08 -------

It indeed looks like my company's sysadmins added a way to support unencrypted
ssh connections.

Looking at the code in cipher.c, it seems it is relatively simple to support the
"none" cipher even for SSH2. I'd strongly suggest that future versions of
openssh support a method whereby encryption can be disabled. This bug gives an
example of a situation where I don't encryption - I'm using a VPN connection that
does the encryption for me.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 11:07 AM

Post #4 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From markus@openbsd.org 2004-06-07 05:07 -------
it's unlikely that "none" will ever be supported. use "arcfour" instead.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 11:24 AM

Post #5 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-07 05:24 -------

My company went out of the way to add the "none" support to ssh. And I'm seeing
postings on comp.security.ssh where several people have asked for this feature.
So why is there a resistance to support the "none" cipher ?

I've given a valid reason too - I don't want to increase overhead with encryption
(specially over a VPN channel that itself does encryption) - I'm using ssh to
compress the data being sent to the X server. Even so, the responsiveness of the
X server is not too good. It'll help if openssh were to provide an unencrypted
channel.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 11:43 AM

Post #6 of 49 (906 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mouring@eviladmin.org 2004-06-07 05:43 -------
The whole point behind SSH protocol is not to leak sensitive information and to stop MITM attacks.
Where the second may not be an issue with ssh2 protocol due to the HMAC usage, but I still have to ask
why would one want to throw away the security around private information?

Even if you encrypt authentification aspect of SSHv2 and left the sesson in clear text you still could leak
information when you connect to other machines or using 'su' or 'sudo' to upgrade your security.

I think it is better if you believe that your machines can't handle encryption is to test the preformance
to find a lowest cpu power encryption or buy a few encryptor cards to put into heavily used machines.

- Ben

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 11:44 AM

Post #7 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

mouring@eviladmin.org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |indy94538@yahoo.com

------- Additional Comments From mouring@eviladmin.org 2004-06-07 05:44 -------
*** Bug 878 has been marked as a duplicate of this bug. ***

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 11:56 AM

Post #8 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From indy94538@yahoo.com 2004-06-07 05:55 -------

My bug was marked a duplicate of this one - so I'm adding in my opinion.

First, this is a matter of separation of policy and mechanism. Openssh should
provide the mechanisms - in this case the "none" cipher - and the policy of
whether or not to use it should be left to the user. This much is standard
systems practice.

Mohit has already given one situation where encryption is undesirable - the
data is already being encrypted by the VPN. Over such a connection, Ben's
concerns related to leaking data with unencrypted ssh channel doesn't apply.

What openssh can do is to disable the "none" cipher in sshd by default. Let the
sysadmins explicitly add "none" as one of the acceptable ciphers in
/etc/ssh/sshd_config. That way the policy will be left to the administrators
with reasonable defaults. Another safeguard might be to throw a warning message
in the ssh client when the "none" cipher is being used. But I firmly believe
the mechanism still needs to be supported.

In the absence of the "none" cipher, companies are themselves hacking the
openssh code to provide support for it. This is obviously undesirable as doing
so might cause other unexpected bugs to creep in.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 12:12 PM

Post #9 of 49 (899 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-07 06:12 -------

Here is a posting made by Richard Silverman on comp.security.ssh that makes
several good points in support of this bug:

BU> ??? What is the point of using ssh or scp without a cypher? Just
BU> use ftp, or rcp or whatever. It is NOT secure.

This point of view is much too simplistic; a connection is not just
"secure" or "not secure" as if flipping a light switch. An SSH-2
connection using a null encryption cipher still has:

- server authentication and man-in-the-middle attack protection
(i.e. you know who you're talking to)

- cryptographically assured integrity protection (i.e. you know the data
is passed unchanged from one end to the other)

- strong client authentication (assuming obvious mistakes aren't made,
such as using password authentication over an unencrypted connection --
most implementations disallow this)

So, if you don't care about privacy, but do care about these other
properties, then using SSH with a null encryption cipher makes perfect
sense. Similar motivations are behind the existence of AH mode in IPSec
as well as ESP. In particular, it makes *no* sense to compare unencrypted
SSH with "FTP, or rcp, or whatever;" these are entirely different.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 12:17 PM

Post #10 of 49 (900 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-07 06:17 -------

> The whole point behind SSH protocol is not to leak sensitive information
> and to stop MITM attacks.

As my previous posting quoting Richard Silverman points out, these are not the
only reasons for using ssh.

Another reason (adding to the list by Richard) is to use compression. Very useful
when forwarding X connections over the Internet. Again when done over VPN, the
encryption from ssh is just an unnecessary overhead.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 4:22 PM

Post #11 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From djm@mindrot.org 2004-06-07 10:22 -------
You aren't listening. The symmetric crypto is not the bottleneck:

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
rc4 72846.67k 82979.15k 87698.53k 91231.05k 88004.03k
hmac(md5) 2272.39k 8280.19k 28745.41k 71355.13k 120523.95k

See: the per-packet MAC is an order of magnitude slower than the symmetric crypto.
The MAC is always included, even with Cipher=none.

There is no point in supporting Cipher=none if all you are doing is introducing
new risks without improving performance.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 5:43 PM

Post #12 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From dtucker@zip.com.au 2004-06-07 11:43 -------
The "none" cipher is listed in the draft protocol spec as "OPTIONAL/NOT
RECOMMENDED".

It's also worth noting that the "none" cipher has been the source of at least
one security problem (in SSH 1.2.x):
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1010

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 11:34 PM

Post #13 of 49 (899 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-07 17:34 -------

> The "none" cipher is listed in the draft protocol spec as "OPTIONAL/NOT
> RECOMMENDED".

The draft obviously doesn't consider situations where encryption is unnecessary
(e.g. a VPN connection). The decision on whether to use or not use the none
cipher should be left to the user (or the sysadmin who sets the policy on
sshd) - currently its been forced on both.

> It's also worth noting that the "none" cipher has been the source of at least
> one security problem (in SSH 1.2.x):
> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1010

If the sshd daemon allows the none cipher even when the sysadmin configures it
not to, that's not the fault of the none cipher - that's a bug in the
implementation.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 6, 2004, 11:58 PM

Post #14 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-07 17:58 -------

> See: the per-packet MAC is an order of magnitude slower than the symmetric
> crypto. The MAC is always included, even with Cipher=none.

This is not true. A look in the data integrity section in:

http://www.openssh.com/txt/draft-ietf-secsh-transport-14.txt

shows that the MAC is also optional. If one is using ssh on a VPN connection,
it is quite reasonable to get rid of the ovhds of both the encryption as well
as the MAC. An example again is when one is forwarding X connections using ssh
over a VPN connection.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 1:01 AM

Post #15 of 49 (908 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From dtucker@zip.com.au 2004-06-07 19:01 -------
> If the sshd daemon allows the none cipher even when the sysadmin configures
> it not to, that's not the fault of the none cipher - that's a bug in the
> implementation.

Precisely! You do not have implementation bugs in features you do not implement.

> draft-ietf-secsh-transport-14.txt shows that the MAC is also optional.

... and that the "none" MAC is "NOT RECOMMENDED".

Also: you mention that you're using a VPN: are you sure there are no sniffers
between the VPN concentrator and the SSH server? A significant portion of
attacks are "inside jobs".

Anyway, have you *measured* a difference? I get wire speed on my long-obsolete
170MHz SparcStation on its 10Mbit/s segment:

$ scp -o MACs=hmac-md5-96 -o Ciphers=arcfour linux-2.5.0.tar.bz2 platypus:/tmp/
linux-2.5.0.tar.bz2 100% 23MB 1.0MB/s 00:23

The CPU is not saturated (and more CPU is spent on network IO than crypto:
CPU states: 22.3% idle, 38.4% user, 39.4% kernel, 0.0% iowait, 0.0% swap)

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 1:25 AM

Post #16 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From djm@mindrot.org 2004-06-07 19:25 -------
Running ssh protocol 2 without a MAC renders sessions vulnerable to active as
well as passive attacks.

Therefore, the chances of us implementing the "none" MAC are even less than that
of the "none" cipher. Feel free to patch your own OpenSSH distribution, but
don't say we didn't warn you.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 9:44 AM

Post #17 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-08 03:44 -------

> Precisely! You do not have implementation bugs in features you do not
> implement.

But you can always also have bugs in features that you do implement and that
compromise security. Not implementing a feature for fear of bugs is hardly
an argument.

> Also: you mention that you're using a VPN: are you sure there are no sniffers
> between the VPN concentrator and the SSH server? A significant portion of
> attacks are "inside jobs".

There might be. By choosing the none cipher, the user has explicitly
indicated that privacy is not of concern here - e.g. he might be simply doing
an scp of some huge binary log from his home to his office machine. Doesn't
matter if anyone is able to sniff out the data on the inside. Leave the choice
to the user - don't force it on him.

> Anyway, have you *measured* a difference? I get wire speed on my
> long-obsolete 170MHz SparcStation on its 10Mbit/s segment:
>
> $ scp -o MACs=hmac-md5-96 -o Ciphers=arcfour linux-2.5.0.tar.bz2 platypus:/tmp/
> linux-2.5.0.tar.bz2 100% 23MB 1.0MB/s 00:23
>
> The CPU is not saturated (and more CPU is spent on network IO than crypto:
> CPU states: 22.3% idle, 38.4% user, 39.4% kernel, 0.0% iowait, 0.0% swap)

10 Mbps networks hardly imposed any ovhd on the CPUs - my company is starting
to use 1 Gbps networks - there the ovhd can be significant. Also Solaris has a
high ovhd network stack - even though you're doing considerable work at user
level, the kernel still comes out having high ovhd. Try a Linux/BSD stack
instead.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 9:54 AM

Post #18 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-08 03:54 -------

> Running ssh protocol 2 without a MAC renders sessions vulnerable to active as
> well as passive attacks.
>
> Therefore, the chances of us implementing the "none" MAC are even less than that
> of the "none" cipher. Feel free to patch your own OpenSSH distribution, but
> don't say we didn't warn you.

I cannot force your hand of course. But I again feel that these are policy
decisions that should be left to the user. If a user chooses Mac=none, he
obviously should be aware of the security risks. If his environment permits
those (e.g. over VPN and transferring public data), openssh should allow him
to turn off the cipher/mac and get higher performance.

These days ssh seems to have completely replaced rsh/telnet - why run rsh/telnet
when you have ssh that gives you many more features such as compression, port
forwarding, security etc. Unfortunately, it seems there's no way for the user
to achieve higher performance when security is not required. People are ending
up patching their ssh distributions - which is very risky compared to the
developers themselves providing the option.

If people are really opposed to providng cipher=none and mac=none options,
is it possible to provide an option to the "configure" command so that these
options can be put in when the build is appropriately configured ? E.g. a build
made after running "./configure --support-plain-text" should make appropriate
ssh/sshd binaries where the cipher/mac can be turned off. That way people like
me can at least make builds appropriately without the need to start hacking
into the code.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 10:24 AM

Post #19 of 49 (899 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mouring@eviladmin.org 2004-06-08 04:24 -------
> I cannot force your hand of course. But I again feel that these are policy
> decisions that should be left to the user. If a user chooses Mac=none, he
> obviously should be aware of the security risks.

Problem is most don't understand. Just like most kids that find guns don't
always understand that pulling the trigger causes it to fire. Why would we
want to endanger our users any more than we have to? And like aways it is
"never the user's fault".. It has to be the software and programmer. Even
if they are abusing the software in a way it was never designed to be used in.

<shrug> My view is if a company wants to hack mac=none, ciphers=none into their
SSH code. That's fine. Not as if it is that hard or complex. However, if they
are now taking that risk into their hands, and can't blame us for not thinking
through how they use the feature.

> If people are really opposed to providng cipher=none and mac=none options,
> is it possible to provide an option to the "configure" command so that these
> options can be put in when the build is appropriately configured ?

Which I strongly object to. Either code should be used or not be included.
Having additional code paths that are not compiled by default only adds more
complexity to testing and platform verification. Plus it litters the source
code with #ifdef/#endif garbage that makes it harder to read and understand.

It's bad enough we have to test compile for PAM, KRB, and other oddball
platform security configurations that affect how the code acts and reacts to
configuration files and other user input.

> 10 Mbps networks hardly imposed any ovhd on the CPUs - my company is starting
> to use 1 Gbps networks - there the ovhd can be significant.

Sounds like you really want to invest in encryption hardware. Sokeris group
sells a nice PCI/PCMCIA solution that runs under BSD/Linux for a very nice
price. I've seen a few gigabit cards with encryption chips right on it. Which
would be another good path to look at. That would make more pratical sense than
gutting security from an application.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 11:24 AM

Post #20 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From indy94538@yahoo.com 2004-06-08 05:24 -------
> Problem is most don't understand. Just like most kids that find guns don't
> always understand that pulling the trigger causes it to fire. Why would we
> want to endanger our users any more than we have to? And like aways it is
> "never the user's fault".. It has to be the software and programmer. Even
> if they are abusing the software in a way it was never designed to be used in.

A naive user can be protected in the following ways: (1) having the command
line options "-o Cipher=none" and "-o Mac=none" are arcane enough that most
ordinary users won't know about them - finding them out would require reading
documentation which would give then sufficient warnings, (2) these options
would only work if the sshd allows them - thus a naive user won't be able
to shoot oneself unless the system administrator explicitly permits these.

> My view is if a company wants to hack mac=none, ciphers=none into their
> SSH code. That's fine. Not as if it is that hard or complex. However, if they
> are now taking that risk into their hands, and can't blame us for not thinking
> through how they use the feature.

Why would someone ever blame the developers if they're providing sufficient
warnings both in the code and documentation and if the defaults do not allow
this unsecure mode. And I've seen the changes that our own administrators have
made to support Cipher=none - they are easy once you know where to put them.
Learning where to put them is what takes the time. If one does it incorrectly,
there is always the danger of introducing bugs - e.g. even making initial
user authentication unsecure. If a feature is being widely requested (and this
one I believe is), its the developers who're most qualified to provide the
appropriate changes to the code.

> > If people are really opposed to providng cipher=none and mac=none options,
> > is it possible to provide an option to the "configure" command so that these
> > options can be put in when the build is appropriately configured ?
>
> Which I strongly object to. Either code should be used or not be included.
> Having additional code paths that are not compiled by default only adds more
> complexity to testing and platform verification.

By eliminating all ways of having a ssh channel without encryption, you're
hurting seasoned users who know what they're doing. And a seasoned user may
not be competent enough to actually go change the openssh code to remove
encryption.

> Plus it litters the source code with #ifdef/#endif garbage that makes it
> harder to read and understand.

It doesn't have to be done using #ifdef/#endif. Even when used, they can
be restricted to some header file. Anyways, code complexity is hardly a reason
to justify not providing a widely requested feature.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 11:41 AM

Post #21 of 49 (899 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-08 05:41 -------
> My view is if a company wants to hack mac=none, ciphers=none into their
> SSH code. That's fine. Not as if it is that hard or complex.

I took a look at the way my own sysadmins have added the "-c none". Seems
like they've had to add a "none2" for SSH2 (as I mentioned in my initial
posting) to get around the fact that "ciphers" in "cipher.c" already
contains a "none" for SSH1. Looks pretty arcane to me. The sysadmins probably
wanted to minimize code changes. Had the developers supported a "none" in
SSH2, that would have been a much better job. In addition, I don't see
support for a "hmac=none" in our code - possibly they didn't realize that
hmac also eats away the performance. So having users do these code changes
is certainly far from optimal.

> > 10 Mbps networks hardly imposed any ovhd on the CPUs - my company is
> > starting to use 1 Gbps networks - there the ovhd can be significant.
>
> Sounds like you really want to invest in encryption hardware. Sokeris group
> sells a nice PCI/PCMCIA solution that runs under BSD/Linux for a very nice
> price. I've seen a few gigabit cards with encryption chips right on it.
> Which would be another good path to look at. That would make more pratical
> sense than gutting security from an application.

I thought ssh encryption works at user-level - how would having encryption
in the network cards help ? It might help for VPNs where the IPsec resides
in the kernel. Anyhow, with tight IT budgets these days, a solution that
requires expensive hardware for hundreds of machines is not viable.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 12:09 PM

Post #22 of 49 (901 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From jason@devrandom.org 2004-06-08 06:09 -------
> 10 Mbps networks hardly imposed any ovhd on the CPUs - my company is starting
> to use 1 Gbps networks - there the ovhd can be significant.

The overhead also is dependant on how you've setup your GigE network. Most
OSes and network devices are pretty configurable and you can really mitigate the
effects of the NIC overhead in your boxes. GigE flow-control is also a must in
any higher-traffic GigE network. I'm pushing 990mbps in testing with very low
CPU overhead on Linux through a variety of tuning practices.

However the added bulk of encryption traffic on the network is going to be
negligible and realistically the encryption overhead in the CPU shouldn't be
that much of a resource starvation to your machines. If it is, then you're in a
business-case ROI for upgrading or replacing H/W based on your needs. Or
changing your usage on the boxes (i.e. use something unencrypted like telnet).

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 12:12 PM

Post #23 of 49 (899 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From markus@openbsd.org 2004-06-08 06:12 -------
1) how much faster is "none" compared to "arcfour"?
2) not having "none" makes it harder for people to send plaintext by accident
3) you still have to use integrity protection
4) it's too easy to screw up the ipsec setup
5) sshd cannot tell whether the connection is protected by ipsec.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 12:20 PM

Post #24 of 49 (898 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-08 06:20 -------

> The overhead also is dependant on how you've setup your GigE network. Most
> OSes and network devices are pretty configurable and you can really mitigate
> the effects of the NIC overhead in your boxes. GigE flow-control is also a
> must in any higher-traffic GigE network. I'm pushing 990mbps in testing with
> very low CPU overhead on Linux through a variety of tuning practices.

Darren Tucker was trying to make the point that kernel ovhd was higher than
encryption based ovhds at user-level. All I'm trying to say is that he should
try on recent hardware/software. One reason why earlier kernels had higher
ovhd in the network stacks was because the tcp checksumming was done in
software. These days Gigabit cards offload it to the NIC. Today it is highly
unlikely that ssh over Gigabit would show higher ovhd in the kernel than at
user-level if the encryption is done in user-level software. It is possible
to offload this user-level software encryption to a special hardware device,
but such hardware devices are not the norm.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none" [ In reply to ]

bugzilla-daemon at mindrot

Jun 7, 2004, 12:27 PM

Post #25 of 49 (900 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=877

------- Additional Comments From mohit_aron@hotmail.com 2004-06-08 06:27 -------

> 1) how much faster is "none" compared to "arcfour"?

You guys have the numbers - as long as its faster I want to use it. Like I said
its painful forwarding X over the Internet, I'd like to get as much performance
as I can.

> 2) not having "none" makes it harder for people to send plaintext by accident

Not having "none" makes it impossible for everyone to send plaintext - this
hurts people who know what they are doing.

> 3) you still have to use integrity protection

Not in situations where its not needed. If I'm transferring a data file
containing a public domain rpm, I'm happy with the integrity that tcp
checksumming offers.

> 4) it's too easy to screw up the ipsec setup

Are you saying its too easy to compromise IPsec security ? As long as I trust
the security offered by my VPN, I want to use plaintext ssh channels over it.

> 5) sshd cannot tell whether the connection is protected by ipsec.

So should sshd enforce security even when connection IS protected by ipsec ?
I think not - that decision should be left to the user.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.