RE: report on EV and SSL MITM proxying

After 15 years of trying and 10 major vendors, isn't it a bit surprising
that none of them have reduced it to a trivial easy UI? It's so easy!

 

Hardly a logical argument; peter. Far too empirical!

 

Try to go through Ryan's argument; he actually answered you logically. In
defending EV, he distinguished it from other server certs that *some*
browsers will not clearly characterize as having been MITM'ed. Having thus
acknowledged the world of SSL MITMing as a fundamental threat, he then
suggested: perhaps look for user id protocols OTHER than TLS client authn.
He outlines how the world involving any cascade of SSL MITMing proxies
(needed for social/corporate "interests") interferes with end-end client
authn, precluding its use beyond interaction with the first proxy in the
sequence. He didn't say it, but this is not a real constrain if that proxy
is now a websso IDP, than translates the layer4 assertion into a layer 7
signed token that bypasses transport bridging.

 

Not really my words, and really not my argument. I just elicited the words
and arugment from folks that others here *should* find reputable.





 

From: Henry Story [mailto:henry.story@bblfish.net] 
Sent: Tuesday, March 08, 2011 12:03 AM
To: peter williams
Cc: public-xg-webid@w3.org
Subject: Re: report on EV and SSL MITM proxying

 

Some folks suggested that life would be all rosy, in webland, if the browser
displayed which client cert had been presented to a given website (per tab,
presumably). How come those over-complicating security designer types, just
don't do simple and obvious things, when its ALL so EASY if one just thinks
minimally and logically!

 

I have not seen an argument in what you have put forward that shows that
this is not an easy thing to do. The only arguments from browser vendors I
have heard, is that client certs are not widely used, and so it has not been
a priority for them.