previously, Russ said...
>>To me, the inherent insecurity of Java is that it is supposed to be viewed
>>as secure.
>
and Ray replied...
>"I disagree. Java is only as secure as its architecture / design /
implementation /environment permit."
Sorry Ray, but I find these kinds of statements pretty condescending.
It applies to everything everywhere. Of course, any *thing* is only
going to be as secure as its
architecture/design/implementation/environment permit, so what's your
point. The Java applet is meant to run inside a reference VM that is
supposed to be secure. If it isn't secure, its not by design, its by
fault. Where that fault lies is irrelevant, JavaSoft say that the VM
should be trusted to the extent that, if properly implemented, it cannot
be broken out of. They say that I can trust a Java applet not to be
malicious, but so far, the implementations of the VM have not been able
to live up to that expectation. JavaSoft still says that they will be
able to assure us of the VM, eventually. Netscape keeps putting out
versions that say they have fixed the VM to prevent malicious applet
>problems.
ActiveX, on the other hand, doesn't claim any responsibility whatsoever
for what an object can or cannot do. They do not try to give you a
sandbox, you have to make that yourself.
The inherent integrity check is part of what proving ownership is all
about. They are able to prove that the object has not been tampered
with, which is what I assume you are referring to when you say "inherent
integrity check". They cannot prove that the object will not be
malicious, or that it will not contain a virus, only that it is the same
as the one they put the signature on in the first place. If the original
object had a virus in it when it was signed, then you will get infected
with a virus, period. What I'd like to see are additional signatures
from third parties telling me that the object has been checked and
deemed not malicious, or secure, or virus free, or whatever...something
more than just "its from Microsoft so trust it". So yes, the signature
is made from a hash of the object.
>
Ray said...
>"Ahhh, another hot topic. Seems to me that this is an implementation
>question that everyone faces. Dealing with certificate revocation is a
>handfull. Seems to me that checking with the CA each time is an
implementation option in most schemems? Can anyone comment?"
Its not an option in IE 3.0b2, nor is it intended (at this point) to be
an option in any MS implementation of the API (according to their
>evangelists).
>
Ray said...
>"As I believe is always the case unless: 1) The CA always checks it's
revocation list or maintains an active list of ALL certiciates - and /
or - 2) The client always asks the CA to do so. True?"
If #2 doesn't happen, #1 is only useful for clients that have never
>accessed the object before.
>
Ray said...
>"From my read of implementor's concerns with making increased security
available, the performance hit of such things as having the client ask
>the CA to check upon every access - although I'll bone up on ActiveX and
figure this out."
I have many ideas of how to solve this problem, but I am trying to make
them into a commercial product. Performance doesn't have to be an issue
>at all.
>
>previously, Russ said...
>>This doesn't represent a problem for the sale of software, but it obviously
>>represents a problem if ActiveX objects are used the way Java applets are
>>used.
>
>and Ray replied...
Not necessarily, me thinks. Looking at the Java 1.1 Security API
>(shipping late Summer or early Fall) it looks like these are all
>implementation choices.
Well, the Security API is not released on JavaSoft's web page, so any
idea where I can get a copy? By the way, we are talking apples and
oranges here. My issues with Java have to do with the Virtual Machine,
not the Java language. The VM imposes restrictions on what language
components you can use in an applet. I suspect that the Security API may
allow better implementations of the VM to be created, but who knows when
or how well. Today, in the VM, we simply get a SecurityException thrown,
which some VMs ignore, or alert yet proceed. A list of constraints the
VM imposes on applets can be seen at;
http://java.sun.com/books/Series/Tutorial/applet/security/security.html
>previously, Russ said...
>>I agree that securing the VM should be possible, but so far, its been
>>impossible to guarantee. Sun and Netscape may be very security conscious,
>>but the simple reality is "can we ever completely trust them?".
>
and Ray replied...
"No, and they say so - explicitly. All they say: if you follow these
>rules, you'll have X level of security (modulo the bugs, implementation
>errors, and brain fade in application of the technology to the problem at
hand, deployment, operations, and management, of course.) Just like the
>sane firewall vendors and any other sane security product vendors.
To quote from the VM Security Restrictions page from JavaSoft's web
site; "One of the main goals of the Java environment is to make browser
users feel secure running any applet. To achieve this goal, we've
started out conservatively, restricting capabilities perhaps more than
necessary. As time passes, applets will probably get more and more
abilities. "
This sounds diametrically opposed to your statement of what Sun has
supposedly said.
Ray said...
>"I disagree. If you want to be secure, you can be. Its all in the defintion
>of what this means to each organization and wheather they will pay the price
to meet their goals."
Come on Ray, the Security API is not yet published, let alone
implemented on a reference platform, let alone included in a commercial
product, so what do you mean you can be secure? You could pay the price
to have someone program you a way to screen applets, and you could also
pay the price to implement full desktop security covering everything
from soup-to-nuts. Bottom line is that if you want to feel totally
secure with Java applets (or ActiveX objects) today, you have to screen
them out, period. Give me one example of a completely secure,
commercially available, browser available today that will run Java
applets, or even a combination of browser and some kind of screening
server that will give me complete security. The price is irrelevant, if
my goal is to be able to trust Java applets, as Sun says I should be
>able to, I cannot meet it today.
>
Ray said...
>"I disagree. It will be as scure as you make it. If there are ActiveX
>defficiencies, those who want to use it will have to ensure that those
defficiencies do not defeat their security goals - just like firewalls
and any other security product."
You must be talking about a completely in-house environment here,
otherwise how can I ever *ensure* that a third-party object does not
contain deficiencies that compromise my security goals, with technology
available today? Even with future technology, unless both Java applets
and ActiveX objects include far more identifiable information in them
(bit patterns, or whatever else it takes for something to determine what
an object is going to do before it executes), then how will I be able to
>enforce my security goals?
>
Ray said...
"The OS's protection mechanisms must allow implementers to protect the
>comm protocols stack, applications.... - as they choose - past the basic
>design requirements of the OS's protection mechanisms. That is, in some
>cases, the basic design requirements of the OS's protection mechanisms
*preclude* everything except a very, very narrow set of comm protocol
>stack, application... functions. In other cases, the basic design
>requirements of the OS's protection mechanisms *allow* everything. The
>balance point is found in building an OS that offers a variety of protection
>mechanisms. Unless I'm on a diferent planet here, these are calledSingle
Level (security) Systems and Multi Level (security) Systems,
respectively."
Next to the former Vice-President of Liberia's request for a room to
bonk his girlfriend in, that has to be the most confusing paragraph I
have ever read. I'm sure you had a point there, but for the life of me I
>have no idea what it was.
>
>previously, Russ said...
>>Something developed for Netscape stays in their Browser (until they release
>>a complete OS that is), and so the scope of the product is somewhat more
>>limited (IMO). Products like Nortel's eNTrust can be extended to have the
>>ability to do far more than just handle objects arriving via the browser.
>
and Ray replied...
"Ummm - IMHO, both (and all others) rely on the afore-mentioned
>property: the OS must support and protect the security mechanisms that use
>them - they can not stand on their own. Sorta like a house of cards in my
view."
Ummm, isn't this just like the VM that Sun says will protect you from
rogue applets? Of course, and once again you state the obvious here, any
security mechanism that is put on or into an OS is going to have to
integrate itself with the OS sufficiently to secure it, and anything
else its intended to secure. The success or failure of a security
mechanism will depend greatly on the original design of the OS, and how
the OS allows security mechanisms to interface with it. However, so far
no implementation of a completely secure OS has been anything other than
user hostile (IMO), so its not yet commercially viable to do complete
>security on a widespread basis.
>
>previously, Russ said...
>>The Java language, on the other hand, is a very different animal than Java
>>applets.
>
and Ray replied...
"Yes - language vs program, true?"
No - program vs. applet that runs in a VM! Both use the Java language,
>but they are very different animals.
>
Ray said...
"IMHO they can't be seperated. If the language does not support
>security features, programs written in them - more of less by definition -
can not be secure."
As virus in DOS have proven over and over again, if I intercept
acceptable calls and redirect them somewhere else, I can change the
basic functionality of the environment. So if I intercept all calls to a
disk drive and respond properly with malicious information, the OS does
not know the difference. In the case of applets, the VM prevents
normally acceptable Java language functionality. In this case, its the
security and integrity of the VM, not the language. I agree, however,
that in writing the VM the security features of the language are
incredibly important, as is the security features of the underlying OS,
>although Sun believes they can make a secure VM on most OS'.
>
Ray said...
"Agreed. Further, I assert that this can not be done w/o an OS that can
properly protect those security mechanisms."
You're article has seemed to have shifted focus from Java to operating
systems. Java is intended as an open language capable of being
>implemented on any OS, don't forget that.
>
>Cheers,
>Russ
>...eek, quick, someone give me some broken software, I'm suffering beta
>withdrawals...
>
|
|
