Great Circle Associates Firewalls
(March 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: JAVA
From: nkeenan @ gsionline . com (Mr. Nick Keenan)
Date: Fri, 22 Mar 1996 18:12:11 +0000
To: Firewalls @ greatcircle . com

>        Went to a demo put on by Sun Microsystems.  At the demo, the Sun
>"dude" proposed the concept that the current version of Java wouldn't allow
>you to write do disk or even to ROM/EPROM/EEPROM on any system at either end
>of the line.  Do you folks have a different take on that.  This was a
>gentleman from Sun who actually writes Java code.
>        His statement was tempered by the fact that they are working on a
>way to authenticate the source location of the applet/application.  Of
>course, I'm not sure that would matter if someone hijacks your connection in
>the middle (would anyone go to the trouble?).
>
I went to the same demo -- last friday in Washington DC.  Sun is really
pushing Java, and they are running headlong into the security issues that
this list faces every day.  They are walking a tightrope between security
and functionality.

In its current incarnation Java can't write to a file, print, make OS
requests, access the hardware, or connect via TCP/IP to anything other than
the computer that provided the current applet.

Application developers such as myself have been critical: What can it do!
All it can do is display pictures and output sound.  It's a glorified
television set!

Security professionals, on the other hand, generally think it can do to
much.  How does Java verify where an applet came from?  Are the connections
secure?  It its security model to be trusted?

A security problem with Java has already been demonstrated:  it is dependent
upon DNS.  At the demo, the Sun representative admitted to me that
multi-homing and round-robin DNS would both cause problems for Java's
security module.

Over the past six months the Java language has been in something of a
tug-of-war between the two competing world views.  For example, the Java
language specifies support for file manipulation, but if you actually try to
use them in a program you will get a security exception.  Same thing with
connecting to a remote host.

The problem I see is trying to create a one-size-fits-all security model.
Most likely you will end up with one-size-fits-none.  Also, another problem
I see is that Java tries to implement security on the user's desktop, where
what you really want to do is implement it as part of the network and
communications infrastructure.

Just my $.02.  Flame away.

Nick Keenan
Global Securities Information
nkeenan @
 gsionline .
 com
http://www.gsionline.com


Indexed By Date Previous: Re: Watchdog- Unreliable 'last' command
From: Dan Schlitt <dan @ ees1a0 . engr . ccny . cuny . edu>
Next: Clarification on Encryption Export Using CKE
From: thompson @ tis . com (Bill Thompson)
Indexed By Thread Previous: Re: JAVA
From: Scott Barman <scott @ di2 . disclosure . com>
Next: Java
From: mcnabb @ argus . cu-online . com (Paul McNabb)

Google
 
Search Internet Search www.greatcircle.com