Date: Tue, 30 Sep 1997 22:37:16 +0930 From: Mike Smith <mike@smith.net.au> To: Jeremy Lea <reg@shale.csir.co.za> Cc: Mike Smith <mike@smith.net.au>, Peter Korsten <peter@grendel.IAEhv.nl>, chat@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <199709301307.WAA00501@word.smith.net.au> In-Reply-To: Your message of "Tue, 30 Sep 1997 10:07:11 %2B0200." <19970930100711.04631@shale.csir.co.za>
index | next in thread | previous in thread | raw e-mail
> > What has to exist is an adequately secure channel whereby the
> > administrator can connect to the system(s) in question without risking
> > compromise. This has to include geek-in-the-middle attacks, password/
> > cookie sniffing, spoofing etc.
...
> How about something like this... I've haven't put much thought into it, but
> it's based on some ideas I've had for a large distributed database that I'm
> currently working on:
[... rampant over-the-top all-singing-and-dancing Java-PGP monstrosity
elided ...]
Heck, I think that says it all.
Look; all these ideas have great technical merit, but no commonsense.
Stop and think for a few seconds about what actually has to be
achieved in order to make this model work. Visualise how your design
would be used in a few different situations, eg. :
- Single user at home.
- Server in busy ISP application.
- Development workstation.
- Large corp/tertiary network.
Also consider that whatever the interface, it has to work with a
textmode browser (ie. lynx).
> Use signature signing in PGP (or similar). You (root@foo.bar) generate a set
> of PGP keys for foo, and then proceed to sign the public keys of say
> joe@foo.bar (your own account) and admin@bar. These are your trusted
> administrators (you could implement a hierarchy and groups and access rights
> etc. to various services etc.).
Too complicated to be the only security model. What's PGP? "Fred the
new admin needs to to XYZ, how do we give him permission?"
> Within a Java application, attached to your administrative web pages via
> Javascript,
How do we do this? Why does it have to be (ack, spit) Java?
> admin@bar could communicate with the server on foo.bar, asking
> for it's configuration options etc. which it then present in the browser.
> The admin changes these options, and they are passed back to the Java applet
> which generates the necessary magic to sent back to the server, and signs it
> with the admin@bar's secret key (which must be on the browsers machine).
So you can't just use a vanilla browser anyway; it has to have Java and
enough security holes to run PGP on the local system? I don't buy it.
> This also has the advantage that it doesn't require a network connection.
> You could design things in such a way that the communication occurred over
> e-mail, by sending a request for, say, a DNS host add form, which is mailed
> back, and then mail the reply.
This is nice, but basically mandates Netscape for forms-enabled email.
> Just a sketch, I hope that I managed to get this across. Obviously there are
> a lot of details which would have to be sorted out. As you said, the
> interface and the server details are the hard parts.
TBH, even a not-terribly-wonderful encrypted channel between the
browser and server would be the *only* way that I would accept a
browser as an adequate interface.
By contrast, the proposed Tcl application method wins in that :
- It can use any stream encryption for client/server comms (eg. ssh)
- Tcl is portable to most *nixlike systems, Win32 and the Mac.
- Client-side processing and dynamic interaction are implicit.
On the downside, it's a lot more work. So if we can avoid it, that'd
be Just Wonderful.
Keep brainstorming. If you can get past these sort of objections, we
all win.
mike
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709301307.WAA00501>