From owner-freebsd-chat Sat Oct 4 20:55:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA22902 for chat-outgoing; Sat, 4 Oct 1997 20:55:01 -0700 (PDT) Received: from obie.softweyr.ml.org ([199.104.124.49]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA22894 for ; Sat, 4 Oct 1997 20:54:57 -0700 (PDT) Received: (from wes@localhost) by obie.softweyr.ml.org (8.7.5/8.6.12) id VAA07218; Sat, 4 Oct 1997 21:59:22 -0600 (MDT) Date: Sat, 4 Oct 1997 21:59:22 -0600 (MDT) Message-Id: <199710050359.VAA07218@obie.softweyr.ml.org> From: Wes Peters To: Mike Smith CC: chat@freebsd.org Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) In-Reply-To: <199710010650.QAA00865@word.smith.net.au> References: <34320C04.5DB5@xmission.com> <199710010650.QAA00865@word.smith.net.au> Sender: owner-freebsd-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I recently blathered: % I've been developing the prototype for the next generation of my % embedded web server on FreeBSD ;^) where it is working pretty well. % I'm willing to throw this in, if I can convince you (all-inclusive % you here) that it will be sufficiently secure. I can think of a % couple of ways to insure this, but it won't be completely painless. Mike Smith writes: > How do you feel about adding source-IP-based access control? That and > a local sshd in port-forwarding mode would just about do it. The existing version already has a limited form of IP src access control. I'd be happy to extend it in reasonable ways; this is something the product as a whole needs anyhow. I'm not terribly familiar with sshd port-forwarding mode, and we would have to determine if there are browser issues, but I'm always willing to learn. % I believe most security-enabled broswers support SSL communications for % "secure" documents. They also support extended, and *extenable* % authentication protocols, a number of which might be acceptable in % conjunction with SSL. > SSL is, AFAIK, subject to certain undesirable licensing conditions (not > exportable, not available for commercial use, etc.) which may render it > unsuitable. Gurk. How do the commercial server vendors do this? You know, IIS and Netscape Commerce Server, etc.? % The part I'm not certain of is the interaction with Lynx, which I % feel is a necessity for our situation. Another need is a simple % local communications path, so we can use Lynx to setup the machine % via the console, VGA or serial. Perhaps a UNIX-domain socket would % suffice, or even a FIFO. > What's wrong with an ordinary socket talking to the loopback address? Fine, once you have a loopback address. I'm still wondering how early in the installation process we'll be switching to this tool. If you haven't yet configured *any* network interfaces, a UNIX-domain socket created by the server is a pretty sure communications channel. Late enough in the installation, a loopback TCP socket would be no problem. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com