Mailing List Archive

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





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