On Mon, 8 Feb 1999, Greg A. Woods wrote:
> 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."
This is exactly what I mean. The statement above applies unless you
control the outgoing connections. If you do, you only have the in-bounds
to worry about, and those can be prevented from leaking infrmation
uncontrollably by using eg time limits. Another example is using
authentication much more fine-grained. Unfortunatly this gets redicules
very fast, but it certainly is doable.
> 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.
The goal is not to prevent the user from doing what he wants but to
prevent a third party in control of the client computer from doing so.
Your friend in this situation is time. If you are using a separate
hardware authentication mechanism to log in you will be safe if you log
out before the third party attempts to hijack the connection. The
connection will be dead and can not be reopened without the hardware key.
If the connection gets hijacked the third party can be thwarted by
requiring re-authentication each x minutes. Combined with the requirement
that outgoing connections from the "trusted" network must also be
authenticated the actions available to the attacker is very limited.
Unfortunatly it is not a very friendly system to work with either.
The main case for not using rsa/password authentication as far as I see is
that the client computer may not be trusted forever. It is very hard to
safly remove all traces of a file/memory area in any modern os. Chances
are that somewhere the passphrase/password/key will remain. If the
reusable information has never been in the computer there is no such risk.
Peter
--
Peter Svensson ! Pgp key available by finger, fingerprint:
<[EMAIL PROTECTED]> ! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF
<[EMAIL PROTECTED]> !
------------------------------------------------------------------------
Remember, Luke, your source will be with you... always...
