river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Towards Internet Jini Services (trust)
Date Wed, 06 Oct 2010 05:38:11 GMT
  On 10/4/2010 11:43 AM, 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?
One of the interesting problems with mobile code, is how to trust what you 
receive through a third party.  Not that it is less valuable or entertaining to 
hackers to corrupt any arbitrary stream of data between two parties.
> 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.
Using TLS/SSL or some other signed (for validity of content) and encrypted (for 
security of content) streaming protocol, for me, is the only choice we should 
push out onto the internet.
> 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.
What the App Store does, it put value in "being kind", because people will pay 
you to do something useful for them.  What Apple's developers contract does, is 
give them some remedy in the case that you "are not kind" so that they can 
intervene for their customers.

There is nothing that can be guaranteed 100%.  Apple, and their customers, have 
accepted some level of "risk" for the benefits they perceive and receive from 
the devices.

The Android "Marketplace" provides similar comforting provisions, but still has 
no guarantees.
> 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
For 1), the problem is that you have to know ahead of time, what you've agreed 
to, because httpmd: is based on you granting permissions to the codesource URL 
based on your acceptance of its content as being valid.   If the codesource URL 
for something like httpmd: comes to you dynamically, how do you validate that it 
has not been changed enroute?
> 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 :)
In a mostly static world, the unmarshall DOS attack is the thing that seems to 
be the most visible hole left in the system.  The layers in the other places you 
mention provide some level of control, which seems adequately adjustable.

Gregg Wonderly
> 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

View raw message