[ On Monday, February 8, 1999 at 15:13:15 (+0100), Peter Svensson wrote: ]
> Subject: Re: transfering files back along an existing connection
>
> On Fri, 5 Feb 1999, Greg A. Woods wrote:
>
> > 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
>
> This is not necessarily correct. The current session can only be protected
> if you trust the host you are on, but future sessions can not be
> initiated. This _is_ relevant and provides security if outgoing sessions
> are limited to prevent a covert channel from being established.
>
> Basically, as long as the effects initiated from a login are limited in
> time, not trusting the client adds security.
I think I agree, but I'm not quite sure I understand 100% what you're
saying here.
I'm not clear who's security policy you're referring to when you say "if
outgoing sessions are limited...." I suspect you refer to a policy that
might restrict outgoing sessions from the trusted network. In this case
things get very complicated fairly quickly. At this point I should note
that most times I've seen such policies they've been completely
misguided and do not in fact lower the risks they're intended to lower,
and often "cost" a great deal to implement fully. (The costs of
mechanically implementing such policies isn't high -- it's the secondary
costs incurred because of such limitations that sometimes rises above
what should be acceptable limits.) As the sshd(8) manual page says:
"Note that disabling {tcp,X11} forwarding does not improve security in
any way, as users can always install their own forwarders." Anyone who
does not believe this should not be using SSH (or anything like it) in
the first place (and yes, I do mean that exactly as I wrote it).
Of course additional in-bound sessions, even from the same trusted host,
cannot be trusted without re-authentication, *unless* they are tunneled
through the existing session for which trust has already been
established (i.e. using SSH's port forwarding feature).
If on the off chance you're actually refering to the possiblity that the
remote site is trying to prevent covert channels from being established
by limiting outgoing sessions then I refer again to the statement in
sshd(8): "Note that disabling {tcp,X11} forwarding does not improve
security in any way, as users can always install their own forwarders."
I'm assuming that the intent of anyone permitting in-bound SSH
connections is to allow a trusted client (i.e. an authenticated remote
user using a trusted remote host) to transfer files as well as to
initiate login sessions. In fact I would argue that it's practically
impossible to prevent such a trusted client from transferring files
anyway, regardless of whether the trusted channel permits simultaneous
openning of tunneled channels. Even the restrictions inherent in an
IBM-3270 style terminal session don't prevent implementation of file
transfer protocols that can transfer any amount of arbitrary ocets of
data in either direction given adequate time. Doing such transfers
covertly may require additional ingenuity, but is clearly possible.
It's hard to make rules of thumb that will apply to any and all security
policies, or indeed to meet arbitrary requirements, but I'll do so in
this case anyway and say that in general if you're going to permit login
sessions using SSH then there's rarely any reason to prevent trusted
users from using SSH's connection tunnelling mechanism (except as a
support issue if you're using SSH-v1 and don't want to deal with stuck
connections). I'm not sure that implementations of sshd-v2 will provide
adequate logging of tunnelled connections, but if not that's just a
S.M.O.P.
Where the true debate seems to start is whether or not it's safe to
automate user authentication. I would say that generally it is, though
if you only wish to trust a remote client at the time a trusted user is
sitting at a keyboard and actively initiating a connection then you'll
want to either require use of RSA pass-phrases (which the user has
control over); and/or require password authentication (which has its own
"limitations"). I would also say that if you're not prepared to allow
remote trusted users to automate their authentication to at least some
degree then you probably don't want to trust them that much in the first
place (for example you could instead force them to use a bastion machine
as an intermediate hop and then require internal trusted user(s) to
facilitate transfering files to and from the bastion host and the
internal trusted network, and possibly to impose reporting and
verification policies for all files transferred between the bastion and
the trusted network).
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
