Re: WebID-ISSUE-28 (bblfish): How does the WebID protocol (foaf+ssl) interact with TLS proxies [User Interface/Browsers]

My tentative summary of Peter's history proxies below, the one that makes sense, but that may be wrong is that

1. Initially the padlock icon was the only icon a user would see when connected to a server via TLS

2. This would also appear when connected to a proxy

=> there was no way of telling the difference between being connected securely and being connected via a proxy, because the padlock just did not give enough information about what one was connected to. Essentially the whole TLS experience was easy to break.

To fix this browser User Interfaces now give the user in the URL bar a lot more information on the server he is connected to, and there is even a special EV certificate that helps the user determine that he is really connected to a real verified commercial entity. 

Question: what happens when one is being proxied? Does one just only see the proxy information in the URL bar? How to people working in proxy enabled institutions then get to know that behind their trusted proxy they are in fact connected to Amazon, to take a random example?

Pictures or screencasts of people working in such environments would be useful for different browsers.


On 12 Feb 2011, at 15:53, Peter Williams wrote:

> Lets put into the record some solid facts about on SSL + UI - some history about changing the UI so SSL continues to evolve to social expectations.
>  
> We (the web) do have some experience in browser UI + SSL tying, within the last 5 years.
>  
> Once the practice of corporate outgoing MITM (SSL bridging) became institutionalized, the scales of social justice had to re-balance. After all, the public trust on SSL was being challenged: since you are NO longer talking only to the named site when the browser "padlock" shows. Of course, you may NOW be talking to the corporate SSL proxy, that talks to the named site "on your behalf". What had to worry the product managers and their browser brands was the likelihood that from corporate MITM bridging it was only a small step to ISP MITM bridging for home users using the very same browser release. ISPs, after all, already run major caching proxies for non-https traffic (to the benefit of all internet users). And, the inherent last-mile property of the ISP has long made this focus-point the target of "internet governance", much like local phone companies have to exploit the control-point to run CALEA for phone tapping (warrants required) and trap&trace pen-recording (just ask)
>  
> In the EV Forum, folks wanted to support the introduction iof the SSL MITM philosophy - a change in the core security model of https that address "social pressures" on privacy, snooping, spying, consent, etc. But, they also wanted those scales to rebalance, remember. ONe should be proud of that. As a result, folks "designed."
>  
> The net result was that a special class of server certs can now be purchased - the EV cert. Its only available from a subset of the CAs present by default in common browser or OS trust lists.  Using UI metaphors used commonly by the dominant browser makers, when talking to that class of end-site one can have confidence that there is no MITM. Otherwise, without the chosen UI metaphor of presenting a green background to the browser address bar, a billion PC users were supposed to get re-trained to know that the "padlock icon" in the status bar no longer means what it once did. This was supposed to train folks that there were new systemic threats "at the trust level" - that your very assumptions (formed over the previous 10 years of public training) may well now be being undermined, by civil society itself.
>  
> There was more UI change than the green/not-green address bar itself. Design practice had to change, to also require that all popups showed the address bar - which could thus have green and non-green backgrounds. In the infocard space, there were further ramifications - that are the basis of why-we-exist rationale for the informatio card forum, closely tied into the openid foundation's mission.

Received on Saturday, 12 February 2011 17:14:49 UTC