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 16:43:22 GMT
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?

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.
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.

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.

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

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've given a simple idea but I am still unsure if this is a solution or not :)

Michal

On Monday 04 of October 2010 14:38:01 Tom Hobbs wrote:
> Isn't that the basic underpinning of secure web traffic?
> 
> Maybe I'm being overly simplistic, but if I browse to www.mybank.com a
> security handshake happens and then anything that server sends me, be it
> images, JavaScript, data etc, sends me I implicitly trust.  If I log into
> gmail.com or amazon.com or whatever, additional handshakes with those
> (code)servers happens again.
> 
> If I get a service proxy from apache.org, then I can implicitly trust it.
>  If I download a service proxy from dodgyproxies.com, a site I've never
> heard of before, then I shouldn't be suprised if it trashed my machine.
> 
> How is downloading and running a service proxy any different from
> downloading and opening/viewing/running anything else?  I think that's the
> basic concept I'm struggling with.  Think back to the bug in JPEG which
> allowed malicious code to execute when infected images were viewed (I
> forget the exact details), but the point of the matter is; if you only got
> images from places you trusted, you didn't have to disassemble each image
> file to check it for malicious code.  If you downloaded images from other
> places, then, well, it was generally accepted as your fault.
> 
> To me, downloading and running a proxy doesn't seem to be any different
> from downloading an executable script or program from the web and clicking
> on my browsers "Run" button rather than the "Save" button.
> 
> Sim's idea of trusting certain places not to intentionally serve you Bad
> Stuff, appears to me to be a mirror of what already happens anyway.
> 
> What am I missing?
> 
> Maybe the question is just "But where are these trusted places I can get
> service proxies from?"  To which the answer is, "No where yet, we haven't
> decided if that really is the best thing to do."  :-)
> 
> Cheers,
> 
> Tom
> 
> On Mon, Oct 4, 2010 at 1:25 PM, Michal Kleczek 
<michal.kleczek@xpro.biz>wrote:
> > On Monday 04 of October 2010 14:09:06 Sim IJskes - QCG wrote:
> > > On 10/04/2010 01:54 PM, Michal Kleczek wrote:
> > > >> This is why TLS is so important. With TLS you have authentication
> > > >> and encryption in one solution. You can configure the level of
> > > >> encryption and the mechnisms for authentication differently for
> > > >> each application.
> > > >> 
> > > >> It provides you with an end-to-end solution, so you can use any
> > 
> > insecure
> > 
> > > >> path you like.
> > > > 
> > > > So you meant TLS between the client and the service in your previous
> > > > post? But how can the client communicate with the service before
> > > > unmarshalling the service proxy?
> > > 
> > > Before i can start unmarshalling, i need to load the class from the
> > > classloader. This classloader connects to the code providing server.
> > > The classloader and server handshake, and exchange certificates. If
> > > anything is fishy, the connection is severed, and whe only have lost
> > > the few bytes from the handshake.
> > 
> > Sure - I understand that.
> > My point is actually that it requires trust relationship with the code
> > server.
> > In other words - for me to securely communicate with you we both have to
> > trust
> > a single third party (the code server). I don't want that - I just trust
> > you
> > but neither you nor I have the necessary infrastructure to have a trusted
> > code
> > server - can we still securely communicate using GMail as our code
> > server?.
> > 
> > Michal

Mime
View raw message