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 >
