Date: Tue, 16 Dec 1997 23:20:46 -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.971216224301.6411C-100000@darkstar.home> In-Reply-To: <Pine.BSF.3.95.971216222455.18840Q-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Using ssh doesn't avoid copyright issues, unless you are referring only to > the protocol. > > Using ssh doesn't avoid export restrictions; just because it is available > (or orginated) around the world doesn't mean it can be exported from the > US. If it is readily available, why does it have to be exported? Software which is sold can be separated from encryption. Overseas setup is a secondary issue. Clients can be designed to invoke ssh without actually having to be bundled with ssh. > Using ssh doesn't let you use any current browser without setup hassles. > Any solution needs integration. Point the browser to http://localhost:port to start out with, but this is a setup hassle to start out with as you point out. It would be nice to have browsers which could point to an http_ssh://<remote_addr> or ftp_ssh://<remote_addr>, though. But then browser standards have been ceded to Microsoft and Netscape, so such a thing could never or happen (or could it?). If one thinks of http as the greatest achievement of mankind and that no other server protocols will come into existence, then I think that putting alot of effort into https (or is it shttp?) makes sense. But suppose one wants to generate procedures for having automatic encryption of any non-IP encoding protocol, then I think building ssh hooks into new applications may actually make sense. > Using ssh doesn't provide for client certificates. > > Using ssh doesn't provide any way for the web server to know about the > state of the content. Clearly ssh isn't a good idea for transaction oriented on-line exchanges of money. In terms of making information available, but not subject to eavesdroping (anonymous ssh), or restricted to a specific group of people (ssh with specific usernames), then I think ssh with port forwarding makes sense. And especially if other protocols in addition to http are desired. > Using ssh doesn't provide any way for the user to tell that their > information is being encrypted from their web client. That goes back to the browser integration issue discussed above. > Using ssh is too heavyweight (ie. imposes a number of extra RTTs to a > connection setup) for http. Yes. A there are constraints, and one would not want to use it in a high traffic situation -- more computers would be needed and either round-robin DNS or load-balancing NAT would be needed. Still, I see ssh as the best way to start separating applications from crypotography. Charles Mott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971216224301.6411C-100000>