Subject: Re: Policy questions
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 01/03/2004 15:33:52
[ On Saturday, January 3, 2004 at 10:32:43 (-0500), der Mouse wrote: ]
> Subject: Re: Policy questions
> > Also, I'm given to understand there are good [ssh] protocol-specific
> > reasons not to allow cypher=none, but I don't fully understand them.
> Assuming the network is one for which rsh would be suitable, I can't
> see any. I'd like a reference to anything anyone has to the contrary.
If the network is suitable for rsh then just use rsh!
If the network is not suitable for rsh then use ssh.
If you use ssh and you want to trust the authentication and connection
integrity that ssh hopes to provide then you really cannot safely allow
it to use raw TCP connections for file transfers (even if you don't need
privacy and you have some way to verify the integrity of the transfered
file). I.e. you cannot ever safely use "cypher=none" in the way it's
currently implemented in SSH.
Now perhaps SSH could be enhanced with a raw-TCP transfer feature that
automatically used a secure hash to verify the integrity of the
transfered file after the transmission has completed. The hash value
would of course be communicated through the normal secured SSH channel
(i.e. out-of-band of the raw-TCP connection used to transfer the bulk
Note though that regular use of such a facility would be vulnerable to
certain types of traffic analysis, though I don't know if there could be
any way for an attacker to exploit such analysis in conjunction with an
MITM attack on the raw-TCP transfer.
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <email@example.com>
Planix, Inc. <firstname.lastname@example.org> Secrets of the Weird <email@example.com>