Article 1907 of comp.lang.java.security:
In message <yvxrajqzmye.fsf@quip.eecs.umich.edu>
        John Eric Ivancich <ivancich@quip.eecs.umich.edu> writes: 

> "ray wood" <rawood@msn.com> writes:

> > And, if you use a Java-capable browser (which, thanks
> > to JavaSoft, NetScape and Microsoft pretty much
> > includes everybody) you will, from time to time, be
> > downloading applets from standalone Java CGI apps.

> Here you're either very confused or attempting slight of hand.  The
> standalone Java CGI apps you refer to are running on the server NOT
> your own machine and NOT through your browser.  Your machine is
> protected.

I think he just misunderstands CGI (in particular, the fact that CGI
programs can be written in any language).

> > This is inevitable and is why even JavaSoft has
> > announced their plans to add support for authenticated
> > signing in v1.1 (which sure sounds to me like the
> > Authenticode technology providing the basis for
> > ActiveX security).

This seems to be saying 'we should go back to Microsoft's original idea.'
In fact the _idea_ of signing Java classfiles preceded Authenticode (and
there are precedents in other systems before that, of course). From what
I gather, some of the delay was because of the US restrictions on export
of cryptography; Sun/JavaSoft wanted (and still want) to provide an encryption
API, as well as a signature API. Some of it was to get feedback on the
simpler implementation without signing, and some simply lack of manpower.

(If this isn't accurate, someone at JavaSoft please correct me).

> It's been said thousands of time already, but apparently it needs to
> be said again.  Signing provides for accountability but not for
> security!

It's worse than that; it can _only_ provide accountability if designed
and implemented extremely carefully. In the case of ActiveX it doesn't, for
several reasons:

- the HTML can come from a different source than the cabfile. ActiveX
  only attempts to authenticate the cabfile, which is IMHO a serious flaw;
  it introduces a whole new class of third-party attacks, which users may
  not take into account when deciding whether to allow the control to run.
- if "trust all commercial software publishers" is checked, there is no
  indication of exactly which CSP provided the control, and so no
  accountability between CSPs.
- ActiveX implementations don't maintain a historical log of which
  controls have performed undesirable actions.
- they _can't_ provide such a record, because there is no restriction on what
  controls can do. If this was attempted, a control could easily overwrite or
  forge the log.
- since the warning dialog is not repeated for controls already cached on
  the user's machine, a control that attacks only on the second or
  subsequent times it is used is much less likely to be traced.
- there is no reliable way to tell whether a control is doing something nasty
  while it is running. This may become obvious only much later (or for a
  passive attack such as stealing/copying data, not at all).
- therefore, when an attack is discovered, the perpetrator could have been
  any of the controls that have previously run on that machine (or any
  machine behind the same firewall, in some cases!)

Note that _some_ of these also apply to the applet signing in JDK 1.1.
IMO, that should be considered a prototype, and not necessarily a model
of how authenticated applets should be implemented. Having a prototype is
valuable, but we shouldn't require future code to be compatible with it.
Let's first learn from the mistakes of ActiveX, and not repeat them in
Java.

> Only to the degree that accountability results in security
> -- and that's an unanswered question -- should one use signing as a
> security mechanism.  And that appears to be the extent of ActiveX's
> "security".

IMHO security is a necessary prerequisite for accountability, not the
other way around. All signing produces on its own is the appearance
of accountability, and only then if you don't look too closely.

The value of accountability is to be able to trace things like social
engineering or denial of service attacks, where _all the security rules
have been correctly enforced_, but the outcome has still been
undesirable (perhaps due to the new features that will allow applets
to read and write files when given permission, open sockets to other
hosts, etc.).

Such attacks can and will happen, and proper accounting features that
allow tracing which applets have run, what they did, and when, would
help greatly in deterring them.

David Hopwood
david.hopwood@lmh.ox.ac.uk, hopwood@zetnet.co.uk