Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Michal Kleczek <michal.kleczek@xpro.biz>
Organization: XPro Sp. z o. o.
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (trust)
Date: Tue, 5 Oct 2010 12:49:59 +0200
User-Agent: KMail/1.13.2 (Linux/2.6.31-22-generic; KDE/4.4.2; x86_64; ; )
References: <4C9DB5BF.8090307@zeus.net.au> <4CAAF9C6.70709@qcg.nl>
 <201010051226.52424.michal.kleczek@xpro.biz>
In-Reply-To: <201010051226.52424.michal.kleczek@xpro.biz>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201010051249.59529.michal.kleczek@xpro.biz>

Of course - I am not talking about the problem of deciding whether I should 
trust a particular service - this is a completely different subject and I am 
not really sure if we should even try to solve it since I don't think it is 
possible to do without human intervention. In the end - choosing to trust and 
use gmail versus yahoo is not something that can be done automatically.

But checking whether an object (code + data) comes from the service I trust is 
something that can be done and is a prerequisite to the above anyway.

Michal

On Tuesday 05 of October 2010 12:26:52 Michal Kleczek wrote:
> 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).
> 
> Michal
> 
> 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