Re: What will incentivize deployment of explicit proxies?

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