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
<[email protected]>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
