From owner-freebsd-chat Tue Dec 16 23:20:32 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA17966 for chat-outgoing; Tue, 16 Dec 1997 23:20:32 -0800 (PST) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA17954 for ; Tue, 16 Dec 1997 23:20:25 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (ras535.srv.net [205.180.127.35]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id XAA03393; Tue, 16 Dec 1997 23:21:19 -0700 Date: Tue, 16 Dec 1997 23:20:46 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home Reply-To: Charles Mott To: Marc Slemko cc: chat@FreeBSD.ORG Subject: Re: Support for secure http protocols In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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:// or ftp_ssh://, 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