On 03/23/2009 09:39 PM, Jack Moffitt wrote: Hi Jack (and others),
Thanks for your thoughtful comments. My argument was indeed that because a webapp - is volatile - and is sandboxed implementing e2e security implies putting trust in the proxy you don't trust because you want to use e2e security. The difference I see between webapp connections and other XMPP/BOSH connections is that in the context of a webapp the codebase of the client and the operator of (at least) the connection manager are in the same hands. When using a stand-alone XMPP/BOSH application, I can choose my own codebase. You are right that the introduction of cross domain techniques and common hosted js-libs takes away parts of my argument. The main reason for me to still write a reaction to you post is not because I disagree, but because I need to 'think aloud' on this topic. > I think this is a real problem but one with real solutions. For > example, you can imagine the case where the apps had some kind of hash > you could check. We're already part way there with common hosting of > libraries like jQuery and Dojo, etc by places like Google. The piece > we're missing is for the browser to actually check the hashes. Very interesting idea. The level of trust I put in a codebase, stand alone or in the context of a webapp is partly based on the possibilities I have to audit it. This idea would make it possible to prove that the codebase running in the browser is the same as a codebase that is publicly reviewed. That would make it much easier to audit a webapp, it would make the code of a webapp from volatile to static and auditable. >> NB: the only situation I can imagine where it might make sense is >> in the project I am maintaining (HelpIM). There the users might trust me >> with software and servers, but still don't want me to be able to see, >> sniff or store in readable format the content of the chats. In other >> words: they trust me in serving a correct end-to-end encryption from my >> server, but still don't want me to be able to see the content of the chats. > > That same argument applies to standards XMPP connections as well. The > threat model is to prevent server operators from viewing your traffic. > You'd already protected for the most part from the world by TLS > between the endpoints. The threat model is indeed the same. The context is, in the current situation where webapps are mainly sandboxed and are hard to audit, a bit different. Normally, if I don't trust a server operator, I won't trust code the operator hands out either. So when using a webapp I have to trust the same entity for both the operation of the server and for the code I use to connect to it and use to perform my e2e encryption, which makes the situation very vulnerable. On a standard XMPP connection I don't have to trust the code of the operator: I can choose my own code to connect to the XMPP service. In the context of HelpIM, I am trusted as server operator and as source of code, but still, for ethical and legal reasons, I am not always trusted with the contents of the chats. E2e encryption with forward secrecy can add an extra layer of security in my context, even if my code has to be trusted and I have to be trusted in distributing a secret. Normally a set-up like this, where it is still possible for me to be a man-in-the-middle, would render e2e encryption useless. In HelpIM it might have added value, because the amount of critical data is reduced from the full contents of a chat to 'just' one secret. Once the e2e channel is established, the secret doesn't need to be secret any more. So both the amount of data that can be attacked and the time-frame in with is possible to attack it, are vastly reduced. regards, Winfried -- http://www.tilanus.com xmpp:[email protected] tel. 015-3613996 / 06-23303960 fax. 015-3614406
