[1604] in WWW Security List Archive
Re: Java "security holes'
daemon@ATHENA.MIT.EDU (Dana Hudes)
Mon Mar 11 15:46:45 1996
Date: Mon, 11 Mar 1996 12:55:18 -0500 (EST)
From: Dana Hudes <dhudes@panix.com>
To: Sarah Green <greens@hsvaic.hv.boeing.com>
cc: greens@cici.com, www-security@ns2.rutgers.edu
In-Reply-To: <Pine.SOL.3.91.960311062655.12539D-100000@hsvaic>
Errors-To: owner-www-security@ns2.rutgers.edu
On Mon, 11 Mar 1996, Sarah Green wrote:
>
> On Sat, 9 Mar 1996, Dana Hudes wrote:
> >
> > Restricting outgoing connections (or incoming!) to the server you got the
> > applet from is a heavy restriction of utility to the legitimate applets.
> > You prohibit two stations on the net from talking, you eliminate data
> > sharing between peers. One cannot have a multiplayer game. One cannot
> > contact a certificate server . One cannot access a database server that
> > is different from the web server.
> >
> Dana
>
> How does the rule 'applet can only talk to hosted server'
> eliminate multiplayer games/training? Why not use a
> daemon on the server (with the applet) that the client
> applet talk to?
>
> IMHO, java applets with a server daemon can be used in all
> of your scenarios. I can even see a few good reasons to have
> only a known daemon talk to the database server (which is probably
> sitting behind a firewall).
>
> Sarah.
> -----
I have several problems with this restriction.
1. Suppose the web server is busy serving up web pages (and applets). It
does not have capacity left to serve as a proxy.
2. The scenario oft-touted at the Java Day tutorial from Sun was using
distrubited objects with OMG-compliant ORB on both client and server. I'm
not clear on how the ORB works but if it were written in Java it could
not work in your scenario.
3. Assume we are not on the public Internet but rather in a corporate
Intranet in the financial world. Assume there multiple servers: web (for
publishing documentation and distributing applets) server farm in which
four machines with distinct IP addresses are listed under a common name in
the nameserver, for load sharing as done by NCSA among others; database
(all that historical economic data for the analysts plus the portfolios of
each user) -- this might have a RAID; a quote server for the equity
markets and another for bonds; trading server, which executes trades.
Assume you have some applets for managing your portfolio and executing
trades which are used by say a thousand traders worldwide (NY, Hong Kong,
Singapore, etc. etc.). Traders are using Netscape on diskless
workstations (I've left off the NFS and TFTP server as they have nought
to do with Java) in a real network-entric computing environment.
You propose that the webserver a user got an applet from is henceforth
repsonsible for proxying all communications to and from the applet.
Do you see the unbelievable extra load on the poor webserver as the
trader interacts with a 3D surface graph of puts on japanese yen futures
with real-time updates (not to mention the extra delay in processing
introduced by the proxying)? Also you 've handily defeated the purpose of
having multiple webservers.
The restriction of only talking to the original webserver is a nice idea
and can be thrown in as default as long as it can be overridden in a
configuration.
