From owner-freebsd-chat Wed Dec 17 11:27:51 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA04894 for chat-outgoing; Wed, 17 Dec 1997 11:27:51 -0800 (PST) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA04874 for ; Wed, 17 Dec 1997 11:27:40 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA09939; Wed, 17 Dec 1997 12:26:59 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA13503; Wed, 17 Dec 1997 12:26:57 -0700 Date: Wed, 17 Dec 1997 12:26:57 -0700 Message-Id: <199712171926.MAA13503@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Charles Mott Cc: Marc Slemko , chat@FreeBSD.ORG Subject: Re: Support for secure http protocols In-Reply-To: References: X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I still think port 22 encapsulation of crypto has alot of advantages. I > acknowledge it doesn't do everything, but suppose a divert socket daemon > exists which does the following. On outgoing traffic, it checks whether a > remote host has sshd. If so, it redirects all traffic to that host > through port 22 using port forwarding. This builds on techniques which > already exist in natd and ppp -alias. Unfortunately, things don't work that way. The only time 'automatic' use of the old ports occur is on unix (not Wintel), and *only* when you are first setting up the connection (again, only on Unix.) This is intended as a replacement for rsh, which doesn't exist on Wintel boxes. > Clients could be completely decoupled from crypto (they wouldn't even have > to know about ssh port forwarding) . Actually, they do. To enable port forwarding, you must connect to 'localhost', and not to the normal host you want to connect to. In short, you can't use SSH seamlessly and expect things to work with/without it. Finally, you mentioned UDP. UDP is not supported, nor do I believe there is any intent to support it inside of SSH. (DataFellows, the folks who make the commercial SSH client for windows has a VPN product that will forward *all* connections to a remote network, but that is even more obnoxious to setup/use than SSH tunnel.) Nate