river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kleczek <michal.klec...@xpro.biz>
Subject Re: Towards Internet Jini Services (trust)
Date Mon, 04 Oct 2010 11:42:46 GMT
On Monday 04 of October 2010 12:37:15 Sim IJskes - QCG wrote:
> On 10/01/2010 03:00 PM, Michal Kleczek wrote:
> > 3. I agree with Tom that making sure the code comes from a known source
> > is enough to make a decision whether to run this code or not. But Jini
> > already checks that (well... almost)- the only hole is that the check is
> > done _after_ deserialization - so it means the code was executed
> > _before_ the check was done. My question actually is - why don't we
> > check an object before it is deserialized?
> 
> A possible solution might be, to enforce code download to use TLS and
> verify if the othersides ceritificate matches the downloaders trustlist.
> We can extends this by enforcing the downloaded jars/classes to be
> signed with a similar certificate.
> 
> A "once bitten measure" could be, if a server violates this rule, it
> will automatically be taken of the trustlist.

I am not sure how it would bring me closer to "The Ultimate Goal" which is to 
make it possible for two parties to securely communicate without relying on 
third parties being trusted or even related with the two parties in any way 
regarding trust - but still allow _using_ those untrusted third parties to 
exchange information.

I don't think it is impossible since I do it all the time - 
switches/bridges/routers are third parties that I do not trust but I use them 
to securely communicate with my bank :) Why code servers or ServiceRegistrars 
should be any different?

We're almost there:
- we have httpmd to stop relying on code servers being trusted
- we have TrustVerifier to stop relying on third parties such as 
ServiceRegistrars or JavaSpaces or EventMailboxes being trusted.

The only ( good question actually :) ) hole is deserialization - a malicious 
ServiceRegistrar or JavaSpace can try a DOS attack before the two parties can 
establish trust.

We can always use RequireDlPermProvider and restrict CodeSources from which we 
allow defining classes. But:
a) it either requires using known code servers (which in turn makes it 
impossible to download code using for example some P2P infrastructure)
b) code signing is expensive - at least the one requiring x509 certificates (we 
do not have PGP or SPKI code signing in Java)

Michal

Mime
View raw message