Re: report on EV and SSL MITM proxying

On 9 Mar 2011, at 09:04, peter williams wrote:

> On Galileo.
>  
> Galileo thought about stuff and reasoned. He was also tortured, by the state of the day, for articulating ideas. That state lives in shame to this day. Like states founded with slavery, history will never forget.
>  
> Put any marketing spin on it you like, seeing if a cert exists in a remote file is not going to qualify as Galilean grade science. First it’s not novel, second it’s not original, third its was all done 15+ years ago. All we are doing is swapping form – one container for another.

Two things:

1- It was not done 15 years ago. 
  
  You keep saying that LDAP was designed to be able to do this. But ldap IDs are not URIs, and neither are LDAP attribute values.  Without a global namespace the previous attempts could not succeed. The important change is in this semantic atom, working together with an architecture - the web - that was built with that as its building block.

2. It is a simple step

Indeed: an extremely simple step. That is why it is invisible to so many.

It requires not much new learning, not many new facts. It requires the security community to go through a paradigm shift, to see anew what they were always looking at. They need to think distributed, when they tend to think hierarchical. They need to think global, where they tend to think closed, they need to think trust where they tend to think distrust.

The idea of the earth turning around the sun is also a simple step: it can be said in one simple sentence. Certainly the Church at the time could argue from its very complicated theory that they had numerous advantages, most of all was established knowledge and past experience. But the forces of globalisation gave new opportunities all the time to those who understood how to take advantage of this conceptual turn.

>  
> Now, I think you are on to something when you want to see the web as a giant computer, one whose atoms can all calculate in RDF’ised Boolean algebra, and jointly compute to find satisfiable expressions of ever greater complexity, of ever wider applicability. And, in that sense, one sees why one wants trust and security – so that contributions to some subweb takes its joint computation ahead, avoiding contamination by the malicious side of human nature. The human world of the human-centric web is messy and somewhat malicious (since it models its creators). The semantic web part is supposedly going to be more machine like, and thus nice and friendly.

Not at all. I don't think the web makes anything nicer and friendlier that it was. It just enables much larger network effects. 

But you can see your old pre globalisation thinking: you are thinking it terms of hierarchical systems that would take the burden off the citizen. But in fact all civilisation is built on trust. What we are enabling is that trust to be expressed all the way down to the citizen: the atom of trust. Or we can put it the other way around. Starting from the citizen as the atom of trust we can build the whole system on top.

But in fact we are not even that reductionistic. We allow companies as entities too, which can have their own WebIDs. When companies give  their employees WebIDs, those do not identify a Person the same way a WebID on a Freedom Box will do, because the company is part of the conversation as we saw with the MITM proxying case.

> (Hmm….. scifi movies about evil robots, notwithstanding)
> But, this is rather ideal, and somewhat abstract. At the same time, it’s a nice goal – one that is not typical “security” – and one that provides us with a wider mission that embodies the semantic web aspects of this project. This takes us beyond fiddling with old SSL, and even older certs, and get us back to the spirit of the webid itself.

yes.

>  
> Of course, it would be nice it actually worked, too, for the countless millions of browsers behind a corporate or ISP firewall that insists on speaking for them, intermediating always. What I hope we learned this week, is that for at least 50% of the web population, today, “the MITM firewall” has immense power to spoof the best that server certs can offer, and will normally prevent the SSL client authn message reaching its target site with connection-integrity – which means webid don’t really work in practice as we defined it in the FOAF+SSL era. It only works in the lab, in conditions too rarified to relate to the real world of SSL, full of nastiness.

Wrong. It works behind firewalls: You get notified that the company wants to look at your transactions, and your transaction is aborted. In those cases you should simply stop doing any private business or get a wireless device.

If companies want to participate themselves and give their employees WebIDs, I proposed a simple way for them to work with firewalls and current browsers. I think if a few companies try that out, then we will have some real people thinking on these issues and with time proposals for the IETF for ways to improve things.

>  
> Which isn’t to say that we cannot change the praxis of https/SSL; where certs (the proxy path) and/or SSL (the multiplexed path) are GREAT ideas to followup. There is lots of latent power, yet unexploited there. But, I predict, this endeavor is going to involve as much cryptopolitical skill as technical design skill. It’s just the nature of crypto that, like science, make it inherently political – something that really hasn’t changed much since Galileo’s day.

yes. My father is professor of Political Science. So I understand that world well.

Henry


>  
> From: Henry Story [mailto:henry.story@bblfish.net] 
> Sent: Tuesday, March 08, 2011 10:26 AM
> To: peter williams
> Cc: public-xg-webid@w3.org
> Subject: Re: report on EV and SSL MITM proxying
>  
>  
> On 8 Mar 2011, at 18:58, peter williams wrote:
> 
> 
> 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!
>  
> Indeed, it is surprising, and it is easy to improve :-)
> 
> 
>  Hardly a logical argument; peter. Far too empirical!
>  
> So I suppose if Galileo found that the earth turns around the Sun, you would have argued that this was impossible because for the previous million years nobody had thought of it.
>  
> Science moves in weird ways. You can't argue from the fact that something has not been done, that it can't. And you can't argue that because your opponents are rich that they must be right. After all Galileo had the Pope against him. 
>  
> Think rather what is NEW in what we are doing, and think why there was not much momentum for client side certificates.  I explained that already a few times. Client side certs that can only be used on one web site are NOT very useful. They only become useful when useable globally. And they can only do that with URIs. So the problem with client side certs was:
>   - using distinguished names
>   - lack of linked data
>   
> So we solve these problems the rest  is easy. There will then be an incentive to improve the User Interface.
> 
> 
>  
> 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.
>  
> It may be useful to have browsers show that they are using proxy certificates. If this is your UI improvement proposal it sounds ok, but it's not a big deal. You can see why not a lot of time was invested in this.
>  
> 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.
>  
> My argument is that it is not a fundamental threat. You make it sound like TLS does not work. But in fact it works very well. If you are in control of your OS and machine you will not be able to work through these proxies - ie: you will be blocked from revealing information to a third party which is what you want.
>  
> Whatever system you come up with will have this problem: if you need to use someone else's network and they want to see what you are doing and communicating they will be able to argue that they should not pass on the information unless you give them the keys. Be that using TLS, XML encryption or anything else.
>  
> 
> 
> 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.
>  
> Social Corporate interests are not necessarily evil. They are larger agents and if they need to see what is going on their network, they will only be able to do so if you accept to give them access to your machine. And this will be so whatever technology you use.
>  
> So in fact the legal uses of TLS work correctly, the illegal uses of TLS work correctly. There is a gray zone with corrupt CAs, but that will be dealt with ietf DANE and DNS-SEC. 
>  
>  
> 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.
>  
>  
>  
> Social Web Architect
> http://bblfish.net/
>  

Social Web Architect
http://bblfish.net/