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 ? -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 security at triumf.ca
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1> (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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE6stHqswXMWWtptckRAmGbAJ9p/6D+jvq8F+NFcP+uVouOxjautQCg9HUX DpxWaAjo+Ynr/FqzE81qDhY=jPY5 -----END PGP SIGNATURE-----
On Fri, Mar 16, 2001 at 04:37:04PM -0800, Andrew Daviel wrote:> 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.
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 On Fri, 16 Mar 2001, Andrew Daviel wrote:> > 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 ? > >