RE: report on EV and SSL MITM proxying

Perhaps I should be less opaque, since I don't like standard cultures that
hide and keep confidences amongst only some of the participants. I should
not break my own rule!

 

One solution is to do client authn over SSL handshake with a null bulk
cipher in the ciphersuite. Should this be detected, there is little  reason
for an outgoing firewall to MITM.

 

Now, there is an offer, inviting an offer back. The firewall give up total
interception, and the SSL end-end client authn gives up confidentiality of
(end-end) identity assertions.

 

This limits the applicability of webid (obviously, it's now no good for
voting.. or supporting the various nym style regimes); but then, its only
supposed to be "better" than "'basic auth' over https" (while also promoting
RDF and the FOAF project). It's a deal I could live with (not that I have
the slightest influence). Using CBTs (channel binding tokens) in the webauth
(e.g. Windows-based Digest) allows the peers at least to detect when the
channel to an https/webid-accepting IDP has been tampered with.

 

 

 

From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of peter williams
Sent: Monday, March 07, 2011 4:42 PM
To: 'Ryan Sleevi'; public-xg-webid@w3.org
Subject: 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?)