Re: report on EV and SSL MITM proxying

On 9 Mar 2011, at 12:18, peter williams wrote:

> 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.

If telcos such as Sprint did this, then browsers that did not have their certificates on their computer would not work. So people downloading browsers would notice this immediately.  The only place where browsers are not downloadable usually are on cell phones. 

There is a serious political issue in my view in letting  providers of telecommunications into conversations like this. I think it should be raised and fought at that level.  Trying to find technical solutions around this cannot work, because if telcos think they have a right to do this, then they will think they have a right to block any encrypted conversation, and derail any standard, and place themselves in any point of control.

So my answer here is that with SSL it is easy to understand what is going on at least. Let us prove if telcos are doing this, and let us make it visible.

The issue is quite plain: it is one of identity. If a large telecoms organisation is doing this, then they are destroying the legal basis on which things can be brought to court. Because it can always be argued that whenever you thought there was 1 suspect, there are in fact 2: the snooping organisation AND the other one. 

> Of course, this is the case you consider, over and over (albeit in the corporate case, vs the ISP case).

The corporate case in my view is somewhat justifiable. It would be nice if it were visible in the browser.

Perhaps someone could put together a simple TLS service: "Is your connection being listened to?" I think this could be a service to develop on the FreedomBox, because as you have access to it, you could trust both sides of the connection.

>  
> 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?

I would be upset if my telco thought it had the right to listen to my conversations, even if everything I post is open source.

>  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.

I think more interesting would be a web service that could make it really easy for you to verify if your SSL connection is being proxied, and by whome. You could then decide if you are ok with this. 

    This will be a fun one to develop. So we got a TODO out of this thread.

Henry


>  
>  
> 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. 
>  
>  

Social Web Architect
http://bblfish.net/