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 Tue, 05 Oct 2010 10:26:52 GMT
Don't know if we agree or not :) . So to make it simple I'd say that the way 
proxy verification is done in Jini is IMHO fine - except that it is done too 
late (after deserialization which requires running yet untrusted code). Once 
we have it fixed - we're basically ready for the Internet ( sure there other 
issues to solve but IMHO this is the most basic).


On Tuesday 05 of October 2010 12:11:18 Sim IJskes - QCG wrote:
> On 10/04/2010 06:43 PM, Michal Kleczek wrote:
> > Let me explain my position better:
> > 
> > IMHO the problem to solve is: how to securely exchange information
> > between two parties without trusting third parties that u use to
> > send/receive it?
> By using cryptography.
> > Your example with JPEG is actually excellent to illustrate my point. The
> > only way to make sure you got your images from a trusted party is to
> > _always_ use TLS - no web caches/proxies or anything like that. Once you
> > have those - you're out in the dark.
> Even when your HTTPS session goes through a proxy, it is still
> end-to-end. (unless you are victim of a MITM attack).
> > It is no different than exchanging objects using untrusted
> > ServiceRegistrars or code using untrusted code servers. It is actually
> > no different than downloading a web page from your bank site - the bytes
> > you actually download come from an untrusted router somewhere in the net
> > anyway.
> But the mere fact that this router is untrusted does not reduce the
> level of security.
> > Also - relying on trusted third parties to download code gives you false
> > sense of security - users of Android or iPhone that download apps from
> > (trusted) app stores should already know that.
> I'm not sure this creates a false sense of security. I've never thought
> is was secure. Did you? I much rather have my third party to be open
> about its practices than not.
> > The solution is not to reject using proxies or any third parties. It is
> > to 1. introduce a way for you to make sure the data you've just
> > downloaded comes from the right source - no matter what means you used
> > to download it. 2. restrict downloaded code as much as possible
> The solution that is brewing does not reject proxies or third parties.
> It is more about accepting them, and remembering the trust choices we
> have made, and means to change this trust.
> > Jini is almost there - we have Java security to restrict downloaded code
> > and we have a way to verify if an object came from a trusted source. The
> > only problem is that to do that we have to run some yet untrusted code.
> > Let's just try to solve this problem :)
> I'm still not sure if we agree or differ in opinion. Are you?
> Gr. Sim

View raw message