Re: What will incentivize deployment of explicit proxies?

Agreed. Also, there's no way for a MITM to distinguish between supported
and unsupported devices. It has to terminate all 443 traffic and so devices
that do not have the proxy CA installed receive a scary message about an
untrusted cert. Better would be if the explicit proxy negotiation somehow
involved clean messaging to the user in this case.

Peter


On Tue, Dec 3, 2013 at 7:42 PM, William Chan (陈智昌) <willchan@chromium.org>wrote:

> On Tue, Dec 3, 2013 at 4:34 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
>> On Tue, Dec 3, 2013 at 4:22 PM, William Chan (陈智昌) <willchan@chromium.org
>> > wrote:
>>
>>> OK, it sounds like people are retreating back from the
>>> autoconfiguration+interstitial part of an explicit proxy proposal...except
>>> maybe Nicholas? I'd love to hear more thoughts on
>>> autoconfiguration+interstitial. It sounds like the prevailing sentiment is
>>> it's unacceptable from a security UX perspective.
>>>
>>> And now we're back to one-time setup operations. And in contrast to MITM
>>> proxies, we see an opportunity to improve on the UX here, since installing
>>> a root cert sucks. It seems like all browsers here rely on the system for
>>> proxy configuration (Pat corrected me earlier on that), so this will tie us
>>> to OS versions if we pursue this path. So if the OS vendors do not improve
>>> the UX for installing MITM proxies, and instead focus energies on creating
>>> a better explicit proxy configuration UX, then maybe that'll encourage
>>> proxy operators to deploy more explicit proxies.
>>>
>>> That's probably most of the proxy incentives there.
>>>
>>
>> I'm not sure that this is the case.  One nice thing about explicit
>> proxies is that they do not need to be on-path, where interception proxies
>> do.  You could imagine someone creating a business that puts the explicit
>> proxies into a data center and selling that as a service.  One of the
>> issues with interception proxies is that you must cause the traffic to
>> traverse the network segments where the interception takes place.  Being
>> able to avoid that would be a big incentive, if the web ecosystem supported
>> it.
>>
>
> Indeed you are correct here.
>
>
>>
>>
>> Ted
>>
>>
>>
>>> Now it's interesting to analyze the site operator incentives and the
>>> browser incentives. Site operators will like explicit proxies, since they
>>> probably like having more knowledge/power. Although there's the concern
>>> Stephen raised earlier about banking site operators blocking access if an
>>> explicit "trusted" proxy is present. This may impact the incentives of
>>> proxy operators to deploy explicit proxies since they may not want site
>>> operators to be able to do this. Thoughts on that?
>>>
>>> And now there are the UAs, of which browsers are the most prominent. For
>>> tools like curl, I don't think they'd have a problem with "trusted"
>>> proxies, since the user presumably knows what he's doing? Maybe? For
>>> browsers though, I expect there will be some hesitance to sacrifice e2e
>>> security guarantees. Pat already mentioned this earlier about his dislike
>>> of proxy termination of https:// requests. My teammates have similarly
>>> voiced concerns here. Would we be willing to move forward with explicit
>>> HTTPS proxies (UA<=>proxy TLS connection) without any "trusted" modes? Or
>>> is that a key part of the proposals?
>>>
>>> Cheers.
>>>
>>>
>>> On Tue, Dec 3, 2013 at 3:07 PM, Martin Thomson <martin.thomson@gmail.com
>>> > wrote:
>>>
>>>> On 3 December 2013 14:37, Yoav Nir <synp71@live.com> wrote:
>>>> > It might be prudent to sacrifice expediency and block all access
>>>> through
>>>> > unrecognized proxies. Adding an explicit proxy would then have to be
>>>> done
>>>> > through a different UI, not a prompt that surprises a user who is
>>>> trying to
>>>> > do something.
>>>>
>>>> That's exactly what we've decided to do for screen sharing in WebRTC.
>>>> It's got a similar sort of security profile: deceptively simple, but
>>>> in practice there are subtleties users cannot be expected to evaluate.
>>>>  In that context, Chrome - the only browser thus far to even have
>>>> screen sharing support - have decided to move access to this into
>>>> their extension framework.
>>>>
>>>> In order to enable screen sharing in Chrome, sites will need to use an
>>>> extension that enables screen sharing for their site.  That hasn't
>>>> been a universally popular decision, but I believe it to be a
>>>> reasonable one given the nature of the problem.  It takes the decision
>>>> off the critical path; it allows for revocation of rights when there
>>>> are bad actors; etc...
>>>>
>>>> I'm not suggesting that this is the right decision here, but some
>>>> greater awareness of the sorts of things people are doing when
>>>> presented with similarly tough decisions can't hurt.
>>>>
>>>
>>>
>>
>