From owner-freebsd-isp  Tue Dec 16 19:07:40 1997
Return-Path: <owner-freebsd-isp>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA29143
          for isp-outgoing; Tue, 16 Dec 1997 19:07:40 -0800 (PST)
          (envelope-from owner-freebsd-isp)
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 TAA29137;
          Tue, 16 Dec 1997 19:07:37 -0800 (PST)
          (envelope-from cmott@srv.net)
Received: from darkstar.home (ras519.srv.net [205.180.127.19]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id UAA03188; Tue, 16 Dec 1997 20:07:31 -0700
Date: Tue, 16 Dec 1997 20:06:58 -0700 (MST)
From: Charles Mott <cmott@srv.net>
X-Sender: cmott@darkstar.home
To: chat@freebsd.org, softweyr@xmission.com
cc: questions@freesbd.org, hackers@freebsd.org, isp@freebsd.org
Subject: Re: Support for secure http protocols
In-Reply-To: <34973506.B112548D@xmission.com>
Message-ID: <Pine.BSF.3.96.971216195732.6298A-100000@darkstar.home>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-isp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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. 

Charles Mott