Re: report on EV and SSL MITM proxying

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

> Try to Remember, an ldap URI is a URI. Certs issued in the windows worlds have had ldap URIs in them for a dacade, now. Try to remember also that X.509 preceeds ldap’s first glimor of existence. Arguments tying ldap to the originality of testing for certs existence in a directory records just don’t fly.

ldap URIs are theoretical URIs. They never really worked in a global namespace. Just compare it to the success of FTP or HTTP uris. 

The fact that people came up later with a URI scheme is irrelevant. We are speaking about why using URIs ( that work ) changes everything. Especially: it turns things that before were theoretical possibilities into practical possibilities - so it can give real incentives to browser developers to do something to improve the latest bugs.

Remember the thread of this argument: client certificates are so broke because of crypt politics. My answer: no they are broke because they were not practical.


> May want to study (from 2005 and earlier) lots of interesting work done on short-life client certs, talking to an IDP here:http://grid.ncsa.uiuc.edu/presentations/gridshib-cip-seminar-dec05.ppt. Some ideas from what others have done, in practice, with proxy certs, IDPs, TLS client authn and a non-conventional https conception. This work is still ongoing (and Tom will happily talk for hours about it..). Should also to talk to David Chadwick’s group on PERMIS, since they tried hard to introduce complex authorization/policy languages there (similar to the IETF proxy cert work, with its focus on policy languages). Little took, in the general web, though.

Mike Jones, from  Manchester who is working on Shiboleth and things is very interested in WebID work because it opens up the possibilities of the Web to these worlds. I look forward to their report.

>  
> But, to business. Do we accept yet something that is important -  that when a MITM firewall is present (at corporate boundary, or ISP boundary for the public, wired or wireless) that the SSL client authn signature originated by the browser will either not get to the resource server, or if it gets there the nature of the SSL handshake’s integrity service for SSL connections will prove it’s been tampered with (since its bound to the browser->firewall connection, not the firewall->resource server connection)?

Yes.  And that is good. If someone spoofs a remote server your browser should refuse the connection, and give a helpful message explaining what went wrong.

>  
> This is what we have to most deal with. Its strikes to the heart of FOAF+SSL.

No it does not.

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.

    1- When the client has a root certificate signed by the company placed it its browser
    2- When a client does not

In (1) the firewall will seem transparent - but that is ok, because it will be for the computer of an employee.

In (2) the firewall will be impenetrable - but that is ok, because you don't want the company to snoop into your business.

>  
> Now, I believe Ive read the same concern stated also by 2 others in the last few days. I read it from Ryan (who advised looking for any user authn mechanism OTHER than TLS client authn), and I read it from friends at Opera (who minced words about the impact of SSL MITMing on client authn, trying to find a diplomatic spin). As I said in my initial report, it’s a spin zone – with vendors trying to craft a looking-forward and modern story distinct from what https simply is no longer what was originally sold: an end-end security protocol guanteed by the power of crypto and the inherent magic of certs.

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. 

( There is the special case of the rogue CA root certificate. But DNSSEC and DANE should make that attack a lot more difficult. )


>  
> What was interesting to me most was that the statements were elicited from folks evidently strong influenced to act in defense of EV. EV is evidently a sensitive topic, sufficiently emotive to have folks rationalize and defend its design principles. While EV is on the one hand just a better originally-qualified server cert, it’s coming across as more than that – being a response to the SSL MITM issue that emerged after 2000 – insofar as it works to that end. It’s really broaching topics traditionally out of scope in https: consent, notice, interception, control, etc etc.
>  
> Take a good look at Tom Scavos’ material, and related technical specs. Folks have been at  trying to make client certs work “effectively” for a long time! His work has long been about mixing IDPs, https client authn, and ldap pulling of user records from a directory, given a name in a cert.

Yes, if you start trying to build a global system with LDAP you have no hope of succeeding. 

>  
>  
> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Henry Story
> Sent: Wednesday, March 09, 2011 12:59 AM
> To: peter williams
> Cc: public-xg-webid@w3.org
> Subject: 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/
>  

Social Web Architect
http://bblfish.net/