RE: report on EV and SSL MITM proxying

Ok. Let's end the thread. I'll provide no more (unless the slights get
worse).

 

Take the case that you are using a sprint browser, manufactured using the IE
specialization kit for OEMs. (Ill assume the same exists for Mozilla.) It
allows trust anchors to be inserted into the list, by Sprint the ISP. I used
to have one, which is a fact. At home, given the nature of Sprint marketing,
you install the browser. It has a sprint CA in the trust list, that the
ISP's proxy (since Im using Sprint as the internet ISP) uses the associated
keys to mint re-signed certs for SSL servers, minted on the fly as part of
SSL MITM. Of course, this is the case you consider, over and over (albeit in
the corporate case, vs the ISP case).

 

Now, sprint on receiving the browser https connection request processes it,
and per SSL MITM, makes a connection on your behalf. To whom does it make
that connection?

 

Does it ALWAYS make it to the server in the URI?

 

Being a proxy, for all anyone knows (and the browser does not), it may make
a connection to a second SSL MITM proxy, which also resigns the real
server's cert, using a trust anchor recognized only by the first proxy (and
not by the browser, who is blissfully unaware of proxy2's existence).

 

So, we have a cascade of SSL MITMers, in which the browser only knows about
the last one in the chain. If the second SSL MITMer changed the resource (by
adding an HTTP header say, or reformating the content for a new content
type, or changed the language from English to Dutch on the fly), the browser
would be NONE the wiser. https in this world does nothing to detect  this
kind of integrity attack, since its not an attack on the channel; its an
change made between channels; and there may be any number of such channel
handoffs just as there may be any number of normal https proxies between
browser and website.

 

I'll see if I can mount the case in practice for you: as cascade of multiple
reverse proxies, each doing SSL MITM.

 

I think I just need to install Microsoft TMG on  2 virtual machines, and
have them cascade. Ill invite you to install into your browser the
"corporate/ISP" trust point of just one of them. Your job is to determine
when and when not the second SSL MITM is present, and has changed the
content of a index.htm file that Ill pull from your own server.

 

How's that? A turing test for SSL MITM.

 

 

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

 

 

 

For you to think that it is you must be confusing - deliberately I am
starting to thing now - two things in order to frighten people off adopting
WebID.

 

 

You are spinning all over the place. And you keep trying to make things more
complicated than they are. I smell politics there in big doses.





 

You know you are talking to a secure site, says VeriSign in 1996. Your
credit card is safe in the hands of only the merchant, says Symantec these
days. Urrr. no it's not. Neither are true these days. Because of the MITMing
and the users "strangely" not recognizing the change of color of address bar
(sometimes, for some sites, but not most and for never for those that use
self-signed server certs, or CAs not in the EV forum (e.g. CAcert)), the
credit card number posted over SSL to a million merchant sites is actually
at any number of intermediaries, unnamed, non-disclosed, un-noticed. The
pre-2000 security claim and assurance is vacous, that is. It's social
snakeoil. But what vendor is going to say that!

 

Now I think you are completely wrong.

 

So I demand now that you back up the above with real facts or we can end
this thread.

 

There is no way people can man-in-the-middle I claim without having access
to your machine, and placing a root CA certificate there.