From: Adam Shostack <adam@homeport.org>
Date: Thu, 21 Nov 1996 20:10:50 -0800 (PST)
To: m5@tivoli.com
Subject: Re: Finjan "SurfinGate"
In-Reply-To: <3294C256.6B88@tivoli.com>
Message-ID: <199611220406.XAA07196@homeport.org>
MIME-Version: 1.0
Content-Type: text/plain


Mike McNally wrote:

| Seems to me that putting together an ActiveX control that "sneaks" its
| way through the firewall risk policy wouldn't be hard.  Unless the 
| applet scanner actually simulates execution of the control under a
| variety of input conditions (and we know that's not likely) (but prove
| me wrong, please) there's not much it can do other than poke around and
| check what other DLL's the thing wants to access.  It might be a bit
| harder to be sneaky in Java, but I certainly wouldn't bet I could look
| at an applet and guarantee its safety to any threshold (if I could, why
| not just do that in the browser?).

	Browsers are big, complex bits of technology.  If you built an
applet verifier that ran on a firewall, it could be substantially
smaller than the 6mb of Netscape3.0 (SunOS).  Smaller code is easier
to verify, and less likely to contain bugs.  In addition, you could be
more confident that your policy goals are met in controlling what
applets enter the perimiter that the firewall deliniates.

	Deploying new browsers to every desktop can be challenging.
If you have a java-gw, there is a lesser need for new browsers
everywhere in response to bugs.  Also, you may be able to get the
source to a verifier, but not to the browser.

	Doing a good job in real time would be very tough.  We need
signed capacity requirements, and an organization that will stand by
its certifications of security.  I have at least one client who would
pay for certified ok applets.  (Not certified origin, certified
non-malicious, for various values of non-malicious).

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume