Subject: Re: sshd config?
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Greg A. Woods <email@example.com>
Date: 01/04/2004 18:13:52
[ On Sunday, January 4, 2004 at 16:48:18 (-0500), der Mouse wrote: ]
> Subject: Re: sshd config?
> "ought to". "most". Handwaving. They're playing parent to their
> users. "We think this is too dangerous to let you play with it, and we
> don't care about the cases where even arcfour is unacceptably
> nonperformant" is how I read it.
No, they are not "playing parent".
They are covering their own behinds though, but I see no reason to scorn
them for doing so.
They (and this goes for all SSH developers I've ever heard speak up on
the topic, and many other security folks as well) are simply saying
something like: "If you want to use an insecure protocol then that's
your decision but we're not going to give you the option to use a tool
that has a reputation of providing good security in a way that will
provide no security. Use your own rope to hang yourself, not our rope."
I happen to agree with them 101%.
And I do use RSH, X11, NFS, TELNET, TFTP, FTP, and similar insecure
protocols on private networks; and I use SSH over public networks,
sometimes making use of its virtual private networking ability to create
a secure private network over a public network when I wish to use those
insecure protocols. It's just a matter of doing my best to try to use
the right tool for the job.
Now back to what I seem to remember is the primary topic for this
thread: Like I said before SSH could well do with a hand-holding
mechanism to set up bulk-data transfers which don't require privacy
whereby it would create a raw TCP connection for the transfer and then
simply calculate a secure hash on each end and transfer only the hash
value through a secure channel to verify the integrity of the
transferred data. I think this would be safer than trying to teach
users how to use something like "netcat" and hope they also use "md5" or
similar, and I also think it would be a truly appropriate feature for
some/all SSH implementation to support.
(personally though I don't mind paying the "crypto price" of using SSH
as-is to transfer even bulk non-private data over public networks
wherever I can't use plain HTTP or anonymou FTP or similar)
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>