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
