Re: What will incentivize deployment of explicit proxies?

One thing.

I think it would be a bit of a push to try to force companies that want 
to deploy a MitM to obtain a CA-issued signing cert for signing the 
spoofed certs.  Many will choose a local CA-issued (e.g. the AD CA 
server) but also many will choose self-signed certs for this.

So presuming that the proxy will be authenticated may not be that 
reliable.

Also I don't think lay people really will have much of a clue what TLS 
means.

I think it's reasonable to take a precautionary default stance as 
proposed (block until allowed).  But each browser vendor will probably 
make their own decision as to what the default is.

I imagine some browser vendors may wish to allow in some environments 
that this can be centrally managed?  e.g. by Group Policy.  This then 
may take away the warning (although a browser could still put up a 
warning to let people know the decision had already been made for them 
by their sysadmin).  That's why I think some permanent visual indicator 
could be useful.  Even if it had a question mark somewhere in it so 
people could see why they were seeing that indicator.

I think though browser vendors will get serious complaints if there's no 
quick easy way for a user to say yes use the proxy.  Each user will 
become a support call.

But these are all browser UI decisions.

We are talking about the protocol here.  I don't think we should pare 
back the protocol to remove choice for users.  Browsers can remove 
choice by deciding what choice to make on behalf of the user, we don't 
have to take the choice away in the protocol.  That leaves zero wiggle 
room if it turns out we made the wrong choice.  Who knows what basis a 
browser may use to choose a default action.  E.g. depending on where the 
proxy is, what site is being visited, some external information etc the 
default may vary and in unresolvable situations the user can be asked.

Adrien

------ Original Message ------
From: "Yoav Nir" <synp71@live.com>
To: "Tim Bray" <tbray@textuality.com>
Cc: "William Chan (陈智昌)" <willchan@chromium.org>; "Martin Thomson" 
<martin.thomson@gmail.com>; "Werner Baumann" 
<werner.baumann@onlinehome.de>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 7/12/2013 12:32:09 p.m.
Subject: Re: What will incentivize deployment of explicit proxies?
>It's hard to make assertions about the UX without knowing how often 
>you're going to come up against a proxy that you haven't seen before. 
>We are willing to cooperate much more with a "first time wizard" than 
>with something that pops up every few minutes.
>
>The only TLS proxy I ever interact with is on the wired LAN at work. So 
>if I get a new computer, I have to teach it only once about a proxy (or 
>install the CA certificate with a MitM proxy). If that's all that is 
>going to be, we can go with a UI like this
>
>+
>| WARNING
>|
>| You can't access your destination: https://www.facebook.com because a 
>TLS proxy is installed on this network
>|
>| The proxy is authenticated, and is called "sslproxy.example.com". 
>Working through this proxy would mean:
>| * that all your SSL traffic is decrypted by the proxy
>| * that all your personal information, passwords and credit card 
>numbers are visible to the proxy
>| * that the proxy could potentially impersonate you for purposes of 
>fraud.
>|
>| This browser is blocking communications since we cannot ascertain 
>whether this proxy is harmful or benign.
>|
>| TLS proxies can only be used if they are configured. To learn more 
>about trusted proxies, click here
>+
>
>I think users can live with that, and read the help, and go to the 
>Tools->Options, or Safari->Preferences, or about:config and set that 
>proxy. This is assuming it's a very rare event. If we get TLS proxies 
>at ISPs, Coffee shops, airports, hotels, and schools as well as 
>workplaces, we'll have to figure something else out.
>
>
>On 7/12/13 1:08 AM, Tim Bray wrote:
>>Whatever we ask people, a very high proportion are going to take the 
>>default. This is independent of how much work you put into the UX. 
>>Thus, it’s very very important that we design things such that the 
>>“default default” is safe, and that it’s difficult or impossible to 
>>configure a network installation with unsafe defaults.
>>
>>
>>On Fri, Dec 6, 2013 at 2:42 PM, Yoav Nir <synp71@live.com 
>><mailto:synp71@live.com>> wrote:
>>
>>     "Don't let anybody kid you. It's all personal, every bit of 
>>business."
>>
>>     In this case, I disagree with Martin. This is not a problem that
>>     we can avoid externalizing. Deciding whether a particular proxy is
>>     acceptable to the user of a browser requires information that we
>>     don't have. We don't have it at the IETF, and we don't have it
>>     where browsers are developed.
>>
>>     A browser can learn of the existence of a TLS proxy. This
>>     information may come from an HTTP code, a TLS alert, DHCP, DNS, or
>>     whatever other discovery mechanism we can think of. Whether this
>>     proxy is acceptable depends on so many factors:
>>
>>      * Who deployed this proxy? (can probably be deduced from name in 
>>its
>>        certificate, but only sort-of) Maybe your workplace is 
>>acceptable,
>>        but the ISP or some other workplace is not.
>>      * What is it doing with the cleartext traffic? Caching? 
>>Filtering?
>>        Recording? Looking for terrorism/criminal activity? Assuring a
>>        non-hostile workplace? There are no technical ways to know 
>>these
>>        things. You'll have to learn them by social means - ask the IT
>>        person, ask your boss, require by law all installed proxies to
>>        disclose what they are doing. None of this can be done by Will 
>>or
>>        his security team.
>>      * Does the product used for the proxy have a recording function 
>>that
>>        can be used in case of a legal mandate? If so, what procedural
>>        mechanism protects the users from someone at IT using it to spy
>>     on them?
>>      * Does the product used for the proxy have a backdoor for
>>        interception? Will and his security team don't know. The boss 
>>and
>>        the IT person may not know that either.
>>
>>     It's a complex decision affected by many objective factors and
>>     some subjective attributes of the user. This is not a decision we
>>     can make on behalf of the user. This is very different from
>>     reporting on a bad certificate.
>>
>>     Hopefully, this will be a rare decision that users don't have to
>>     face every day.
>>
>>     Yoav
>>
>>
>>
>>     On 7/12/13 12:12 AM, William Chan (陈智昌) wrote:
>>
>>         Hey hey, there's no reason to make this personal :) I never 
>>said I
>>         have no responsibility here. I just tried to make a funny quip
>>         that
>>         the...more passionate factions of the larger Chromium project
>>         will be
>>         very...passionate in their response to certain ideas. Is there 
>>a
>>         reason you wish to make this about me all of a sudden?
>>
>>         Let me be clear, I in general think it's terrible to burden
>>         the user
>>         with decisions which they are largely unable to reason about.
>>         And I
>>         think it's wrong to expect them to have the knowledge to
>>         reason about
>>         it. And I disagree with the argument that browser vendors must
>>         provide
>>         all possible configuration options so users can do whatever
>>         they want.
>>
>>         On Fri, Dec 6, 2013 at 1:27 PM, Martin Thomson
>>         <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>
>>         wrote:
>>
>>             On 6 December 2013 12:26, Werner Baumann
>>             <werner.baumann@onlinehome.de
>>             <mailto:werner.baumann@onlinehome.de>> wrote:
>>
>>                 [...] the dogma that users are stupid.
>>
>>             Not stupid, never stupid. It's respect.
>>
>>             UI surface area imposes costs upon users. We cannot -
>>             should not -
>>             externalize our problems by shunting them on users.
>>
>>             This isn't purely a security problem either; there are
>>             security
>>             aspects to this, but they aren't the only concerns. I
>>             expect better
>>             of Will than to try to shift focus onto some faceless
>>             "security team",
>>             he owns some responsibility here too.
>>
>>
>>
>>
>
>

Received on Saturday, 7 December 2013 02:13:18 UTC