"cipher none" alternatives ?

[Andrew Daviel]

We are trying to upgrade from SSH1 to OpenSSH/SSH2.

I see that configuration support for "cipher NONE" was removed in OpenSSH.

Is there an alternative for this ?

We need to move big files (>100Mb) between machines on the Internet. In
the past we had used NFS or ftp but want to block those services at one or
both ends. Moving them with SSH 1 scp takes quite a bit of CPU effort for
encryption. (I had observed that for smaller files scp -c 3des was
noticably slower than NFS/ftp/scp -c none on 100BaseT links, though not on
10BaseT)

The datafiles themselves do not contain sensitive data, but we'd like to
use some better authentication method than ftp and preferably something
that would easily go through a firewall. As I understood things, scp -c
none with RSA authentication offers something like that.

We could presumably use HTTP GET to suck files if they were placed in a
webserver tree and use HTTP authentication. I'm not so sure about pushing
with POST or PUT.

Any suggestions ? Is it feasible to build OpenSSH with support for cipher
none ?

[Dan Kaminsky]

Andrew--

Funny, I was just talking about this with one of the dev guys.

Here's the problem--while what you're moving doesn't have any security
considerations(same here--but I'm moving GPG encrypted files), without a
cipher and the associated per-message authentication that goes with it, you
have no way to prevent an attacker from injecting arbitrary packets or
commands(like rm -rf *).

Sure, *you* might be sending trivial messages, but you can't predict
what *other* people will send. The crypto prevents their messages from
being meaningful.

SSH2 does have a real HMAC per-packet authenticator, and indeed might be
amenable to what you describe--essentially, something similar to AH-mode
IPSec. But someone else will have to say whether the HMAC is capable of
being used in this manner, and performance will never be as high as a
full-out null cipher.

Incidentally--if anyone out there is skilled at profiling code, I think
the SSH client could use a look. I think there are absolute limits embedded
in there as to how fast it may run, because it'll never use up as much CPU
as is available to it and will top out at 150-220K/s no matter the speed of
the client or server.

Yours Truly,

Dan Kaminsky, CISSP
http://www.doxpara.com

[Jason Stone]

(I had observed that for smaller files scp -c 3des was noticably
slower than NFS/ftp/scp -c none on 100BaseT links, though not on
10BaseT)

3des is extremely slow, slower by far than almost any other cipher in
common usage. I remember someone doing some time trials for different
ciphers and posting to the list a couple months ago - check the
archives. In any event, try blowfish or aes instead of 3des.

The datafiles themselves do not contain sensitive data, but we'd like
to use some better authentication method than ftp and preferably
something that would easily go through a firewall. As I understood
things, scp -c none with RSA authentication offers something like
that.

The scheme you're talking about isn't vulnerable to password sniffing, but
it _is_ vulnerable to hijacking. The crypto in this case is serving to
authenticate each individual packet as well as hide the data, so when you
get rid of the crypto, an attacker can take over either end of the
connection, inject packets (containing commands), etc, even though he
doesn't know the password.

That said, there are other authentication schemes that avoid sending
passwords in the clear. CHAP stores the password in the clear but never
sends it over the wire. OPIE (aka, S/Key) is even better as it neither
sends nor stores the password in the clear.

Before ssh was in wide use, I had my users use opie-ftpd.

We could presumably use HTTP GET to suck files if they were placed in a
webserver tree and use HTTP authentication. I'm not so sure about pushing
with POST or PUT.

You could also use crypto here too. Most webservers can trivially be ssl
wrapped (check out stunnel, sslproxy, etc), some webservers have native
support for openssl (apache + mod_ssl is particularly popular), and there
are many available ssl webclients (curl, lynx-ssl, etc). You can use
either HTTP authentication inside of the ssl stream, or, maybe better, you
can require both the client and the server to authenticate each other with
ssl certs. (These roughly correspond to password auth and public key auth
in ssh.) I'm sure that at least one of these combinations can be
configured with a fast, low overhead cipher.


-Jason

---------------------------
If the Revolution comes to grief, it will be because you and those you
lead have become alarmed at your own brutality. --John Gardner

[Rachit Siamwalla]

Post by Jason Stone
The scheme you're talking about isn't vulnerable to password sniffing, but
it _is_ vulnerable to hijacking. The crypto in this case is serving to
authenticate each individual packet as well as hide the data, so when you
get rid of the crypto, an attacker can take over either end of the
connection, inject packets (containing commands), etc, even though he
doesn't know the password.

I'm no crypto guro, but correct me if i'm wrong, can't you just use
secure hashes to protect the data? secure hashes should be a lot faster
than crypting the datastream.

-rchit

[Pekka Savola]

Post by Dan Kaminsky
Incidentally--if anyone out there is skilled at profiling code, I think
the SSH client could use a look. I think there are absolute limits embedded
in there as to how fast it may run, because it'll never use up as much CPU
as is available to it and will top out at 150-220K/s no matter the speed of
the client or server.

I wonder where you got that 150-220K/s number. That's completely untrue.
I've scp'd, using a fast cipher like arcfour (blowfish isn't bad either),
files over 100baseTx LAN at the speed of over 5 MB/s or so.

[Dan Kaminsky]

Post by Pekka Savola

Post by Dan Kaminsky
Incidentally--if anyone out there is skilled at profiling code, I think
the SSH client could use a look. I think there are absolute limits embedded
in there as to how fast it may run, because it'll never use up as much CPU
as is available to it and will top out at 150-220K/s no matter the speed of
the client or server.

I wonder where you got that 150-220K/s number. That's completely untrue.
I've scp'd, using a fast cipher like arcfour (blowfish isn't bad either),
files over 100baseTx LAN at the speed of over 5 MB/s or so.

Interesting! Lemme do some experiments...

Yes, Cygwin OpenSSH SCP -> Linux OpenSSH manages 280k/s 3DES, 350K/s
Blowfish. This is over a wireless card (I use SSH for wireless security),
so I might be bumping into limits on this supposed-11MB/s link.

You've not done Arcfour with OpenSSH; it's not supported. I'm not sure if I
like that or not.

My numbers came from port encapsulation figures, rather than scp command
encapsulation figures. What numbers have you seen when moving, say, files
over a forwarded HTTP link?

--Dan

[Pekka Savola]

This post might be inappropriate. Click to display it.

[Damien Miller]

Post by Dan Kaminsky
You've not done Arcfour with OpenSSH; it's not supported. I'm not
sure if I like that or not.

It is supported for ssh2. ssh -2 -oCiphers=arcfour ...

-d

[Dan Kaminsky]

Post by Damien Miller

Post by Dan Kaminsky
You've not done Arcfour with OpenSSH; it's not supported. I'm not
sure if I like that or not.

It is supported for ssh2. ssh -2 -oCiphers=arcfour ...

***@CISCO-CD5ZTDFXI ~
$ ssh -h
...
-c cipher Select encryption algorithm: ``3des'', ``blowfish''

Self-Documentation trumps--can be a blessing or a curse.

--Dan

[Christopher Linn]

Post by Dan Kaminsky

Post by Damien Miller

Post by Dan Kaminsky
You've not done Arcfour with OpenSSH; it's not supported. I'm not
sure if I like that or not.

It is supported for ssh2. ssh -2 -oCiphers=arcfour ...

$ ssh -h
...
-c cipher Select encryption algorithm: ``3des'', ``blowfish''
Self-Documentation trumps--can be a blessing or a curse.

perhaps the manpage is more current than the embedded help msg?

from ssh(1):

[...]
-c cipher_spec
Additionally, for protocol version 2 a comma-separated list of
ciphers can be specified in order of preference. See Ciphers for
more information.
[...]
Ciphers
Specifies the ciphers allowed for protocol version 2 in order of
preference. Multiple ciphers must be comma-separated. The de-
fault is

``3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,
aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,
rijndael256-cbc,rijndael-***@lysator.liu.se''
[...]

Post by Dan Kaminsky
--Dan

chris

[Markus Friedl]

Post by Andrew Daviel
The datafiles themselves do not contain sensitive data, but we'd like to
use some better authentication method than ftp and preferably something
that would easily go through a firewall. As I understood things, scp -c
none with RSA authentication offers something like that.

"scp -c none with RSA authentication"

does not protect the integrity of the data you transfer.

[Dan Kaminsky]

Post by Markus Friedl
"scp -c none with RSA authentication"
does not protect the integrity of the data you transfer.

Markus--

Say I did something like(yes, I know this wouldn't work out of the box):

ssh -2 -oCiphers none -oMACs hmac-md5 ***@host tar czf - bigdir/ | tar
xzvf -

Would this maintain packet integrity while maximizing transmission
speed?

Is there any argument for supporting arcfour in SSH2 but *not* SSH1?

--Dan

[David Terrell]

Post by Dan Kaminsky

Post by Markus Friedl
"scp -c none with RSA authentication"
does not protect the integrity of the data you transfer.

Markus--
xzvf -
Would this maintain packet integrity while maximizing transmission
speed?
Is there any argument for supporting arcfour in SSH2 but *not* SSH1?

Yes, the security problems in ssh1 (the weak CRC) are more easily
exploited with [A]RC4.

[Markus Friedl]

Post by Dan Kaminsky
xzvf -

yes, this would protect the integrity of the transmission.

Post by Dan Kaminsky
Is there any argument for supporting arcfour in SSH2 but *not* SSH1?

yes.

http://www.kb.cert.org/vuls/id/25309
http://www.kb.cert.org/vuls/id/565052
http://www.kb.cert.org/vuls/id/665372

and probably more.

[Rob Hagopian]

This post might be inappropriate. Click to display it.

[Andrew Daviel]

Post by Rob Hagopian
There's an older thread about this, you can hack in none support really
easily, but I did performance tests between arcfour and none on Dual PIII
850Mhz machines and there was no significant performance difference. One
of the developers here asked for full profiling info but I haven't had
time to assemble it...
-Rob

I've spent a bit of time measuring things between two SGI machines - old
and not-quite-so old. These are multiprocessor machines so the total CPU
effort is quite good for data analysis still though a single task like SSH
will lag a new Intel appreciably. I can't remember the clock speed -
120MHz or something on the older one I think though I believe the MIPS
chip needs less clock cycles per instruction than Pentium (and the
floating point's better)

SGI Irix 6.5 MIPSchip IP27 -> Irix 5.3 MIPSchip IP19 on 100BaseT

4Mb file times given in seconds (transfer time)/(including setup)
comands e.g. time scp2 -c twofish -P 8122 test.dat remote:/tmp

CIPHER
Transport none DES 3des blowfish twofish arcfour idea cast128 aes128 aes256 rijndael

NFS 2.0
ftp 5.3
HTTP 5.5
openssh 7/12 4/9 5/16 5/18 7/19 9/21 7/17
ssh1 5/6.5 10 22/24 7/8 6/6.2 13
ssh2 21/24 26/29 20/23 19/22 20/23 21/24
ssh1->openssh 11/11 5/5.4
ssh2->openssh 15/19 17/21 19/23
openssh->ssh1 21/28 6/11
openssh->ssh2 15/20 8/12 4/7 10/15

84Mb file
NFS 25.42
ftp 104.29
openssh arcfour 114/127
openssh blowfish 117/130

One of our users was talking about moving gigabytes; I'm not sure if a
single file or little ones. They had complained about the time taken
by ssh1 compared with ftp.

It looks like NFS is easily the fastest, then the unencrypted transfers
with arcfour/blowfish on OpenSSH close behind, if you ignore the setup
time (from when I hit return till when the activity indicator starts)
The system had a normal user load so times are not guaranteed.

[Jason Stone]

Post by Markus Friedl

Post by Dan Kaminsky
xzvf -

yes, this would protect the integrity of the transmission.

Though of course, there's going to be a non-trivial expense associated
with MAC'ing. I have no numbers, but I would imagine that the time
associated with md5 hasing is of the same order as the time associated
with crypting equivalent amounts of data?


-Jason

---------------------------
If the Revolution comes to grief, it will be because you and those you
lead have become alarmed at your own brutality. --John Gardner

[Markus Friedl]

Post by Jason Stone
I have no numbers, but I would imagine that the time
associated with md5 hasing is of the same order as the time associated
with crypting equivalent amounts of data?

% openssl speed

will give you numbers.