Re: What will incentivize deployment of explicit proxies?

Yoav,

Good summary of conflicting incentives. I think the key is that eproxy
needs to represent a security improvement. Going from MITM to eproxy should
be seen as going from the insecure 1.x MITM way to do encrypted proxying to
the 2.x more secure way to do it.

Eproxy includes support for:

   - Pinned certs
   - No transitive trust
   - In general, no certificate forgery
   - Any node refusal (or other related scheme that improves server
   visibility and/or negotiates consent)
   - Additional security features??

Improved security interests everyone (servers, proxies, network admins,
browsers, users) as long as the glitches of upgrading are short term and
manageable.

Lastly, it's worth pointing out that this discussion on incentives has
largely focused on the enterprise use case. The service provider (Darlene
and Eliot in Mark's user stories --
https://github.com/http2/http2-spec/wiki/Proxy-User-Stories) will be more
impacted by the increase in encrypted traffic due to HTTP2 requiring TLS
and therefore much more interested in an eproxy standard that makes
optimization possible. I work on such an optimizing proxy for satellite
networks and TLS sites, even with HTTP2, are dramatically slower (often as
much as 4x slower) due to the fact that prefetching/caching/acceleration is
blocked. Without eproxy support, service providers will increasingly look
for ways to implement MITM-based solutions.

Peter


On Tue, Dec 10, 2013 at 11:22 AM, Yoav Nir <synp71@live.com> wrote:

> On 10/12/13 4:12 AM, Mark Nottingham wrote:
>
>> On 10 Dec 2013, at 11:50 am, Stephen Farrell <stephen.farrell@cs.tcd.ie>
>> wrote:
>>
>>
>>> On 12/10/2013 12:44 AM, Mark Nottingham wrote:
>>>
>>>> Sure. I'm thinking in terms of changes in browser behaviour (along
>>>> the lines that some have already explored), not changing TLS, or even
>>>> certs, necessarily.
>>>>
>>> But there is a problem here - as I understand it many root
>>> stores have no controls over the protocols with which the
>>> roots can be used so if you insert a new root then you will
>>> also have affects on non-HTTP protocols that use TLS.
>>>
>> Yes, that's already happening today. Such controls would indeed be nice.
>>
>> <https://www.grc.com/miscfiles/HTTPS_Interception_Proxies.pdf> is a nice
>> writeup, and lists a few products that do this at the end. There are
>> others; e.g., <http://wiki.squid-cache.org/Features/SslBump>.
>>
>> The problem is that installing a new CA is *extremely* common; try
>> searching for "install CA certificate" and you'll see many, many results
>> like <http://community.web.cern.ch/faq/certificate-installation-android>
>>  <-- note that it's even happening where the Web started!
>>
>> Those CAs then have unlimited power to MITM communication (whether that's
>> their intent or not), and cannot easily be detected when doing so.
>>
>
> Even worse, browsers have to work "everywhere". So when faced with such
> MitM CAs, they disable mitigation features such as public key pinning. Nor
> can they afford to change this behavior unless organizations move away from
> using these CAs for MitM. A corporate CA used for corporate servers would
> not need the browser to disable pinning.
>
> But because we don't want to burden the user, we use the heuristic
> installed CA == corporate CA == legitimate MitM proxy. That means miss
> those CAs that got installed through social engineering or a technical
> flaw, but are not legitimate, even though pinning was explicitly designed
> to catch them.
>
>> What I've not seen is anyone who's proposing such changes
>>> (that do affect TLS) volunteering to do that analysis.
>>> I'd say its not an easy piece of work but absolutely
>>> necessary and it might well turn up a conclusion that
>>> this is a bad idea globally.
>>>
>> AIUI we're already there -- i.e., people think it's a bad idea, but it's
>> happening.
>>
>> To be crystal clear -- I'm not talking about making it easier to install
>> CAs in browsers. I'm wondering if we can *constrain* the current practice
>> in a meaningful way, so as to limit the damage of this already-widespread
>> practice.
>>
>
> I don't see how we can constrain it much. We can offer a better
> alternative - a TLS proxy without a CA - and if (when?) using them becomes
> sufficiently wide-spread, a different value of "we" might set a date at
> which browsers will no longer default to disabling pinning when faced with
> corporate CAs signing pinned servers.
>
> The problem is that the incentives here are all skewed:
>
>  * For the servers, pinning might get them in trouble, and agreeing to
>    a connection from an explicit proxy means assuming some risk
>  * For proxy vendors supporting both MitM and explicit proxy,
>    configurable by the network administrator is easy - small cost to
>    us. We can even support both for BC.
>  * For the network administrator MitM works, so why risk turning on
>    eproxy, which might break something.
>  * Browser vendors can implement eproxy, but that might be one of those
>    things that people fail to configure properly. Also, the plan above
>    calls for them to butt heads with the network administrators, who
>    might say, "this browser doesn't work - use that browser (which
>    still disables pins by default)". I don't think it's their job to
>    force people into good security practices.
>  * Users (especially those that use their own devices or Firefox on the
>    corporate device) still have to follow some procedure to define the
>    proxy. It can (but does not have to) be easier than adding a CA
>
> So getting rid of MitM proxies and replacing them with explicit proxies
> requires (a) administrators that are willing to do what's right for
> security at the expense of some support calls in the short term, and (b)
> browser vendors that are willing to risk some disconnects with sites that
> deploy PKP, which is likely to be the same sites that now deploy STS -
> Google, Facebook, Yahoo, Paypal - so, important sites. If you were working
> on Chrome, would you be willing to have the IT department at some places of
> work sending everyone an email that "Following the Chrome update from
> yesterday, Chrome can no longer be used with Google, Facebook, Yahoo,
> Paypal and some others. Please use one of the supported browsers, like ..."
> ?
>
>  We may not be able to (either because it's too hard, or because the IETF
>> isn't the right place to do it), but it's worth talking about. One
>> interesting discussion that's related:
>>    https://code.google.com/p/chromium/issues/detail?id=81623  (CLOSED
>> WONTFIX)
>>
>> What I don't want to do is spend months-to-years developing a new kind of
>> explicit proxy in HTTP in the *hope* that it'll somehow magically supplant
>> these devices, without some sort of evidence that it has a chance of doing
>> so.
>>
>>  I work for a vendor that makes such devices. We'd be happy to change the
> way they work. It's a win for us in many senses. I just don't know if it's
> as much of a win for the other players.
>
> Yoav
>
>