Date: Wed, 17 Dec 1997 08:29:00 -0700 (MST) From: Charles Mott <cmott@srv.net> To: Marc Slemko <marcs@znep.com> Cc: chat@FreeBSD.ORG Subject: Re: Support for secure http protocols Message-ID: <Pine.BSF.3.96.971217073751.6934A-100000@darkstar.home> In-Reply-To: <Pine.BSF.3.95.971216234716.18840T-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> IPsec is really the solution to a more generic solution. I don't see any > room for a hack like this between the two, except in very specialized > situations. [...] > > A lot of work is going into IPsec. Commercial and non-commercial > implementations are available, although somewhat lacking in key > management. That is a far better solution. 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. Clients could be completely decoupled from crypto (they wouldn't even have to know about ssh port forwarding) . If checking for ssh on the fly is too slow, then this could be diabled and a static list of addresses having port 22 support could be used. This would be good for e-mail and and company databases. A secure server would only listen on port 22 and have all its other ports walled off from the outside world. Servers could also be optionally secure. Also, if IP tunneling were embedded in ssh (is it already?), that would solve another big problem all in one coherent framework. And UDP port 22 support would be nice, too. Charles Mott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971217073751.6934A-100000>