RE: report on EV and SSL MITM proxying

Well, if nothing else we have teased out a pretty big assumption buster:

 

From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Ryan Sleevi
Sent: Monday, March 07, 2011 3:40 PM
To: 'peter williams'; public-xg-webid@w3.org
Subject: RE: report on EV and SSL MITM proxying

 

 

Because of this, I think it may also be useful to re-evaluate the use of TLS
client authentication, and consider exploring possible alternatives methods
of identification. 

 

I think the next argument is going to be: add any amount of assurance of the
TLS-based client authn (eID, level 5 certs, . ) it's all to no avail - as
the need to intercept the tunnel is of far greater social need than
facilitating https-based user authentication (TLS Client authn). Simply put,
tunnel interception is more important than TLS client authn, in overall web
culture. And, technically, you cannot have both (1) firewall MITM
interception AND (2) end-end TLS client authn (i.e. (1) and (2) are
exclusive)

 

Is that fair restatement of the core argument?

 

Now, when I talked to the SonicWall folks at the RSA show, they contrasted
their work with Microsoft's Threat Management Gateway product (as vendors
are want to do, when competing). Much as Microsoft was proud of ensuring
that user's MIGHT be warned of the interception act, Sonic was proud of a
reverse re-signing capability in in their firewall - one in which the
firewall would dynamically resign the user cert's cited during TLS client
authn (as received on SSL bridge half between browser and firewall). Of
course, this enables the bridging firewall to spoof the user name ==
SAN_URI, since the eventual relying party no longer has the assurance of the
self-signed user cert

 

So, how do we do what we set out to do (use TLS client authn, and
self-signed certs that point back at a foaf card?)