RE: report on EV and SSL MITM proxying

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