[ On Friday, February 5, 1999 at 17:53:53 (-0800), Joe Rhett wrote: ]
> Subject: Re: transfering files back along an existing connection
>
> Remember the point about risk analysis? Having the hardware based
> encryption devices raised the standard, and makes it even harder to get in.
> It also allows authentication for services which SSH does nothing for.
You're not reading what I wrote Joe. Either that or you don't
understand anything at all about covert channels and trust.
Ignore my warning at your own peril. The Phrack#51 tools are widely
available and it doesn't take a genius to use them. If you really have
something of value to protect then you're not doing a very good job of
protecting it if you allow your users to use un-trusted hosts to open
trusted channels regardless of how much authentication you require of
them. Doing so is like giving a stranger your bank card and it's PIN
and asking him to run down the street and withdraw $20 for you and then
trusting him to only do that *and* to give it back with the $20. Even
if the PIN is only valid for single uses, you're hosed if the guy
decides to betray your trust by taking the risk to withdraw $40 (or your
maximum withdrawl limit even) and only give you back the $20 you asked
for. We've got a VISA commecial running here in Canada that shows a man
at the zoo. He drops his wallet into the chimp cage when taking a photo
and a nice little creature runs down and retrieves it for him. Only
after he's gone does the chimp reveal that he's kept the guy's VISA card
and the cheering amongst his compatriots begins.
You just never know what's going on behind your back when you can't
trust an intermediate party. SSH can only protect your channel *after*
it has left the host which originates the connection. You *MUST* trust
the client host regardless of what authentication or encryption
protocols you employ, or to put it another way, if you use SSH then you
*are* trusting the client host, whether you realize it or not. Given
that I ask again: Why not just trust the client host to store your
authentication key(s) and be done with all the external and hard-to-use
authentication protocols? Just because you trust it while you use it
doesn't mean you have to trust it forever -- it is possible to revoke
trust with SSH from the server side.
> Once again :-( the issue is that SSH/SCP should allow file transfer down an
> existing connection, rather than opening a new connection to transfer the
> files. Looking at the protocol, I don't see any reason why it isn't possible.
Of course it's possible. We've been over this several times already.
You can even script it up using the facilities it provides for you on
the command line (hint: "scp -p"). If you're careful you'll even be
able to get scp to tunnel through an existing slogin connection without
requiring any additional authentication and without doing any additional
encryption over the tunneled connection that's already encrypted by the
parent slogin channel. Of course it'd be easier to do if you didn't
have to trick scp into doing something different when it's tunneled, and
as has been mentioned before there are multitudes of different ways to
do this if you use "socket", "netcat", or even "kermit", or any other
simple tool that permits you to open TCP/IP connections and transfer
data over them.
(BTW, the sooner you learn how to act and interact better in public and
private communications, the better off you'll be too! Please don't send
me any more private mail Joe. I'll correspond with you only in public
as I no longer trust the private channels you open.)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
