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.


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

> On Tue, Dec 3, 2013 at 4:34 PM, Ted Hardie <> wrote:
>> On Tue, Dec 3, 2013 at 4:22 PM, William Chan (陈智昌) <
>> > 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 <
>>> > wrote:
>>>> On 3 December 2013 14:37, Yoav Nir <> 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.

Received on Wednesday, 4 December 2013 01:49:25 UTC