- From: peter williams <home_pw@msn.com>
- Date: Tue, 8 Mar 2011 11:37:29 -0800
- To: "'Yngve Nysaeter Pettersen'" <yngve@opera.com>, <public-xg-webid@w3.org>
Ok. So we are concluding on what any student from a govt cipher school knows: there is the writer-to-reader model of key management, and the intermediated relay model. Nothing has changed in 30 years. The web just evolved more on the relay model (while marketing itself as an end-end model). Now, along comes webid protocol, that aims to change the status quo. I believe that SSL record-layer's design as a multi-session capable bearer is what saves the day, as we can have AND eat the cake. We can on one session be doing user-authn, and on another be doing intermediated document retrieval. If the user-authn session creates SAs (and the bulk encryption is null), nothing stops a document retrieval SA from being negotiated within that outer SA, that the firewall can have access. So, the trick to SSL MITMing is to stop thinking that the SSL MITM properties (setup for document retrieval) have to make life difficult for client authn. There CAN be multiple sessions, distinguished by function. One can be intermediated, one note. One can hope EV solves the "intermediated" issues, for the document retrieval function. One can hope that firewall vendors (and society) can be persuade of the logic of not interfering with those sessions aiming at user-authn to public sites. Of course, if folks are trying to _engineer_ a world of ALWAYS INTERMEDIATED user authn (ie. websso IDP world), there will now be 17 reasons why this use of SSL properties is not viable (starting with: it's not here today). And, if one solves those, there will just be 17 more. Such is the nature of cryptopolitics, as folks vie for control over communications and [commercial] control over the last mile(s) in a relaying model. -----Original Message----- From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Yngve One can perhaps say that using client certificate is the best option to protect against MITM SSL attacks (or proxies), as long as you can trust the server's verification and your own client certificate key database, but then, that is what security always comes down to: Either trusting the endpoints and intermediates, or making sure they cannot interfere without detection, but you still have to draw a line somewhere beyond which you have to trust that there have been no compromise.
Received on Tuesday, 8 March 2011 19:38:02 UTC