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

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 at mindrot.org
        ReportedBy: mohit_aron at 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.

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

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

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From markus at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From mouring at 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.

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

mouring at eviladmin.org changed:

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



------- Additional Comments From mouring at 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.

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





------- Additional Comments From indy94538 at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From djm at 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.

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





------- Additional Comments From dtucker at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From dtucker at 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.

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





------- Additional Comments From djm at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From mouring at 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.

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





------- Additional Comments From indy94538 at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From jason at 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.

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





------- Additional Comments From markus at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From mohit_aron at 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.

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





------- Additional Comments From markus at openbsd.org  2004-06-08 07:24 -------
How can the user tell that the traffic is still IPsec protected?
IPsec is per packet, and after flushing SAs the connection
might be unprotected.  How can SSH tell?

Please show me how much faster none is. here's a patch:

folly% cat dontuse.dif 
Index: cipher.c
==================================================================RCS file:
/cvs/src/usr.bin/ssh/cipher.c,v
retrieving revision 1.66
diff -u -r1.66 cipher.c
--- cipher.c    10 Nov 2003 16:23:41 -0000      1.66
+++ cipher.c    19 Nov 2003 18:01:04 -0000
@@ -60,11 +60,12 @@
        u_int   key_len;
        const EVP_CIPHER        *(*evptype)(void);
 } ciphers[] = {
-       { "none",               SSH_CIPHER_NONE, 8, 0, EVP_enc_null },
+       { "none1",              SSH_CIPHER_NONE, 8, 0, EVP_enc_null },
        { "des",                SSH_CIPHER_DES, 8, 8, EVP_des_cbc },
        { "3des",               SSH_CIPHER_3DES, 8, 16, evp_ssh1_3des
},
        { "blowfish",           SSH_CIPHER_BLOWFISH, 8, 32,
evp_ssh1_bf },
 
+       { "none",               SSH_CIPHER_SSH2, 8, 0, EVP_enc_null },
        { "3des-cbc",           SSH_CIPHER_SSH2, 8, 24,
EVP_des_ede3_cbc },
        { "blowfish-cbc",       SSH_CIPHER_SSH2, 8, 16, EVP_bf_cbc },
        { "cast128-cbc",        SSH_CIPHER_SSH2, 8, 16, EVP_cast5_cbc
},
Index: mac.c
==================================================================RCS file:
/cvs/src/usr.bin/ssh/mac.c,v
retrieving revision 1.6
diff -u -r1.6 mac.c
--- mac.c       18 Sep 2003 13:02:21 -0000      1.6
+++ mac.c       19 Nov 2003 18:01:04 -0000
@@ -45,6 +45,7 @@
        { "hmac-md5-96",                EVP_md5, 96 },
        { "hmac-ripemd160",             EVP_ripemd160, 0 },
        { "hmac-ripemd160 at openssh.com", EVP_ripemd160, 0 },
+       { "none",                       EVP_md_null, 0 },
        { NULL,                         NULL, 0 }
 };
 
folly%



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

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





------- Additional Comments From markus at openbsd.org  2004-06-08 07:35 -------
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      23000.94k    86595.78k   261084.63k   500813.38k   696327.46k

BTW, this is what you'll get with a cheap Via C3 CPU (the CPU does AES).



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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 07:46
-------
> How can the user tell that the traffic is still IPsec protected?
> IPsec is per packet, and after flushing SAs the connection
> might be unprotected.  How can SSH tell?
(1) In some cases, e.g. transferring a large file available publically, it is 
    always ok to do the transfer in plaintext.

(2) If security beyond the VPN concentrators is of concern, the sysadmins
    can refrain from allowing the "none" cipher on sshd.

(3) Ultimately, the judgement should lie with the user. When he uses "-c
none"
    he understands the associated security risks. Users should control the
    policy. A seasoned user can then effectively use it to his/her advantage.

(4) Naive users would be protected if the defaults are reasonable and
    the option to do "none" is arcane and possibly not listed in the
manpage.
    (Even the cipher arcfour is not listed in the manpage for ssh).


I'll try getting the performance results you asked for later today.





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

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





------- Additional Comments From markus at openbsd.org  2004-06-08 07:55 -------
no, with IPsec the user _cannot_ tell if the data is actually protected.
however, with SSH he can.

(and there is no standard API, so SSH cannot figure out
if the TCP session is IPsec protected).



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

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





------- Additional Comments From markus at openbsd.org  2004-06-08 08:02 -------
arcfour is documented in the manpage.

and we won't add undocumented things.



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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 09:42
-------
> arcfour is documented in the manpage.
>
> and we won't add undocumented things.
Arcfour is - but Aes isn't (at least not in the man page for ssh). Neither
is
rijndael.








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

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





------- Additional Comments From djm at mindrot.org  2004-06-08 09:46 -------
ssh_config.5 is very clear:
>   Ciphers
>           Specifies the ciphers allowed for protocol version 2 in order of
>           preference.  Multiple ciphers must be comma-separated.  The de-
>           fault is
>
>             ``aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
>               aes192-cbc,aes256-cbc''




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

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





------- Additional Comments From mouring at eviladmin.org  2004-06-08 09:51
-------
In addition to DJM'scomment...

Rijndael it is the same as aes.   It's there for historical reason and
sometime down the road it will go
away.

- Ben



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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 10:00
-------
> ssh_config.5 is very clear:
How is it clear ? Should one assume that the default implies these are all
the ciphers ssh supports ?

ssh.1 doesn't talk about aes at all. In fact the ciphers available with the
"-c" option are simply blowfish, 3des, and des.




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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 10:02
-------
> Rijndael it is the same as aes.   It's there for historical reason and
sometime
> down the road it will go away.
My point is that it has been added and is undocumented. So is aes.





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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 10:08
-------
> no, with IPsec the user _cannot_ tell if the data is actually protected.
> however, with SSH he can.
The application cannot. The user can - if I've setup a VPN connection
between
my home and office, I know the data is protected when its going to be sent over
it. For this reason, it is the user who is best suited for decided whether he
needs an unencrypted connection with ssh.

And then there are situations where one can use unencrypted ssh even over 
vanilla Internet - e.g. when transferring public domain software.




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

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





------- Additional Comments From djm at mindrot.org  2004-06-08 10:12
-------
> (2) If security beyond the VPN concentrators is of concern, the sysadmins
>    can refrain from allowing the "none" cipher on sshd.
How do you know when you are beyond a VPN perimeter? How do you know some
routing screwup isn't exposing your traffic? How do you know some malicious
insider isn't sniffing? How do you know that the user won't forget that
the
channel is not encrypted and accidentally type a root password into
"su"?
> (3) Ultimately, the judgement should lie with the user. When he uses
"-c none"
>    he understands the associated security risks. Users should control the
>    policy. A seasoned user can then effectively use it to his/her
advantage.
>
> (4) Naive users would be protected if the defaults are reasonable and
>     the option to do "none" is arcane and possibly not listed in
the manpage.
>     (Even the cipher arcfour is not listed in the manpage for ssh).
A non-naive user can patch their OpenSSH installation. I believe that is a much
more appropriate demonstration of their competence and their acceptance of the
consequent risk.



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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 10:22
-------
> How do you know when you are beyond a VPN perimeter? How do you know some
> routing screwup isn't exposing your traffic? How do you know some
malicious
> insider isn't sniffing? How do you know that the user won't forget
that the
> channel is not encrypted and accidentally type a root password into
"su"?
How do you know the user won't forget he's logged in using
'telnet' and then
type a root password into "su" ?

The idea is to make it difficult for anyone to use the unsecure mode, but at 
least permit it for people who really want to.




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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 10:24
-------
> A non-naive user can patch their OpenSSH installation. I believe that is a
much
> more appropriate demonstration of their competence and their acceptance of
the
> consequent risk.
That is not easy - and it requires one to learn the code. The developers should
consider including the relevant code and only enabling it when something like
"./configure --support-plain-text" is used while doing the build.




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

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





------- Additional Comments From djm at mindrot.org  2004-06-08 10:33
-------
> That is not easy 
That is the point




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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 11:12
-------
> That is the point
What's your objection with providing a means to allow this via
"configure" at
build time ?

Letting people unfamiliar with the code mess with it is too risky.




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

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





------- Additional Comments From djm at mindrot.org  2004-06-08 11:18
-------
> What's your objection with providing a means to allow this via
"configure" at
> build time ?
configure options are bad. More choices = more conditional code = more paths to
test = more bugs = more work for us
> Letting people unfamiliar with the code mess with it is too risky.
Then they shouldn't do it, that is the point.

We don't want users to use "none" because we think it is an
unacceptable
tradeoff. Others may disagree, but it is up to them to enable it if they are
congnisant of the risks.



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

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





------- Additional Comments From mouring at eviladmin.org  2004-06-08 11:23
-------
Based on the crap most Linux distros do to packages.  I can almost assure you
that they would enabled
it by default if there was a configure option.   Thus the end users have access
to it without having to
think, and thus people using a feature without understanding what drawbacks.

Don't believe me?  Start digging through some of the *.src.rpm for most
distros and you'll get sick
pretty quick by all the stuff they do because they feel it is
"required".  When in fact it is not.

- Ben



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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 17:25
-------

Based on the patch that Markus had posted for implementing the "none"
cipher and
mac, here is some data I've collected.

I did a transfer of 4 MB from my office machine to my home machine. The transfer
was done using scp over a VPN connection established between my home and office
machine. I did several transfers, varying the cipher and mac for each one. 
Each transfer was able to saturate the bandwidth available to me at the time (by
my Comcast broadband connection) of about 110 KBps. Thus, what's relevant is
the CPU ovhd. My home machine is a 800 MHz IBM T21 thinkpad running cygwin over
Windows 2000, while my office machine is a fancy 2.7 GHz machine running Redhat 
9. Here is the data from my home machine when the transfers were done (CPU was
consistently 82% idle when no transfer is being done):

Cipher          MAC            CPU idle

default         default        55%
arcfour         default        60%
arcfour         none           60%
none            default        65%
none            none           65%

So it appears that disabling the MAC isn't giving me any benefits - or else
the patch doesn't quite disable the MAC.




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

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





------- Additional Comments From djm at mindrot.org  2004-06-08 18:22 -------
QED



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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 18:24
-------

Another experiment I did measured the latency. Basically I wrote a tcp client 
and server program that sent a packet to each other in a ping-pong fashion. 
I did 1000 of these ping pongs, and then computed the avg time for a ping pong.
The ping-pong was done over a channel forwarded using ssh. By choosing different
cipher/macs, I was able to compute the additional latency due to these options.
The setup is the same as that I posted above, with my laptop at home as the 
client. Each packet that was sent was 128 bytes.

Cipher        Mac          Avg ping-pong latency (msec)

default       default      44.90
arcfour       default      43.68
arcfour       none         42.71
none          default      41.87
none          none         41.08

Based on these results, I see a 10% improvement in latency - can be significant
if X is getting forwarded over an ssh connection. 




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

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





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 18:26
-------
> QED
Notice that it doesn't appear that MACs=none is working with this patch. A 
previous posting mentioned that that is a substantial cause of ovhd.



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

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





------- Additional Comments From djm at mindrot.org  2004-06-08 18:32
-------
> Based on these results, I see a 10% improvement in latency - can be 
> significant if X is getting forwarded over an ssh connection. 
If would be if the absolute difference wasn't only 3ms - that well below the
threshold of perception.
> Notice that it doesn't appear that MACs=none is working with this
patch. A
> previous posting mentioned that that is a substantial cause of ovhd.
No, it just demonstrates that the bottleneck for most practical applications
isn't the crypto (which is what we have been saying all along)

BTW you are measuring the absolute wrong thing anyway - the only case where
removal of crypto would have a benefit is high-throughput, low-latency, private
LANs.



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

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





------- Additional Comments From dtucker at zip.com.au  2004-06-08 18:49 -------
You can use ssh -v to verify the cipher, MAC and compression negotiated.  Look
for a line like:
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: kex: client->server aes128-cbc hmac-md5 zlib



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

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





------- Additional Comments From dtucker at zip.com.au  2004-06-23 10:57 -------
Mohit Aron wrote:
> > Rijndael it is the same as aes.   It's there for historical reason
and
> > sometime down the road it will go away.
> My point is that it has been added and is undocumented. So is aes.
Your point about AES is a good one, and the man pages (ssh_config and
sshd_config) have now been updated.

Rijndael is not listed because it's a non-standard vendor extension
that's
equivalent to aes256-cbc and is retained for config file backwards compatibility
only.  (If you put it in your config file then you ought to already know what it
is :-)

 Ciphers
       Specifies the ciphers allowed for protocol version 2 in order of
       preference.  Multiple ciphers must be comma-separated.  The sup-
       ported ciphers are ``3des-cbc'', ``aes128-cbc'',
``aes192-cbc'',
      ``aes256-cbc'', ``aes128-ctr'', ``aes192-ctr'',
``aes256-ctr'',
      ``arcfour'', ``blowfish-cbc'', and
``cast128-cbc''.  The default
       is

         ``aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
          aes192-cbc,aes256-cbc''




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

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

djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From djm at mindrot.org  2004-06-26 09:14 -------
So, like we said: this won't be changing for the forseeable future.




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