From owner-freebsd-chat Tue Dec 16 21:29:22 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11125 for chat-outgoing; Tue, 16 Dec 1997 21:29:22 -0800 (PST) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA11109 for ; Tue, 16 Dec 1997 21:29:11 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id WAA13442; Tue, 16 Dec 1997 22:29:03 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id WAA22783; Tue, 16 Dec 1997 22:27:29 -0700 (MST) Date: Tue, 16 Dec 1997 22:27:28 -0700 (MST) From: Marc Slemko To: Charles Mott 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 On Tue, 16 Dec 1997, Charles Mott wrote: > On Tue, 16 Dec 1997, Wes Peters wrote: > > > So, my question is: if I have the capability (time, interest, etc) to > > implement only ONE secure http transport, which one should it be? There > > is a draft ieft standard for S-HTTP, but Netscape et al HTTP-SSL seems to > > have garnered more support in the real world. > > I've said this once before, but I think the way to go is to operate an > "anonymous" ssh server on the web server, and then have the client > application set up a secure proxy connection to the host via existing the > existing port remapping (-L option) in ssh. > > I think anonymous ssh could have a similar impact to anonymous ftp. Ssh > based clients would use the anonymous user name the same way web browsers > do for ftp right now. > > Ssh and sshd are already universal in the unix world, and the Wintel > variant (F-Secure) is reasonably priced. Why not encapsulate security as > much as possible in an ssh framework? Then developers could stop thinking > about the subtleties and cross-national implications of licensing. 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. Using ssh doesn't let you use any current browser without setup hassles. Any solution needs integration. 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. Using ssh doesn't provide any way for the user to tell that their information is being encrypted from their web client. Using ssh is too heavyweight (ie. imposes a number of extra RTTs to a connection setup) for http.