Re: Yet another trusted proxy suggestion

Hi,

On 11/28/2013 02:41 PM, Yoav Nir wrote:
> On 28/11/13 1:46 PM, Stephen Farrell wrote:
>> Hiya,
>>
>> Cutting out lots of bits...
>>
>> On 11/28/2013 11:15 AM, Yoav Nir wrote:
>>> On 28/11/13 11:37 AM, Stephen Farrell wrote:
>> [...]
>>> With this proposal they can enforce their policy, allowing users to
>>> connect without a proxy, and not allowing them to connect with it. Seems
>>> like a positive to me.
>> You're saying that basically a bank with a policy of not agreeing
>> to expose their customers' credentials to proxies (or with a
>> regulator who imposes such a policy) would have to turn off
>> Internet banking for any customer behind such a proxy who uses
>> HTTP/2.0.
> 
> No. A bank with that policy would have to turn off Internet banking
> period, because MitM proxies work today with HTTP/1.  

We disagree. Since the bank server cannot see the current MITM
attack box, they don't have the problem of deciding what to do
about that today, at the HTTP/TLS level. (Unless sites like
that also shove some JS to the browser that does detect the
MITM box - does/could that happen?)

As soon as we standardise proxy behaviour that does allow the
kind of scanning enterprises claim to need then we've handed
that bank and others this problem - they then need to figure
out if they're ok with customer credentials and data being
exposed to proxies or not and if so, when and to whom.

> HTTP/2 (as opposed
> to /1) does not figure into this.

Depends. As I understand it the proposal is to define this as
a feature of HTTP/2.0. I'm not clear how it could be done with
HTTP/1.1. But we don't need to figure that out right now, I
think the more interesting question is about the consequences
for sites and if those arise in an HTTP/2.0 version that
supports this kind of proxying then that's enough to know for
this discussion.

>> I've no real clue, but I'd worry that'd be a major dis-incentive
>> for deploying HTTP/2.0 for such a bank. (Is there even a good
>> way to fall back to HTTP/1.1 in such a case?)
>>
>> Doesn't that mean that the wg need to know whether or not the
>> above speculation is real or not before any particular proxy
>> solution could be adopted? (Or before someone takes the risk
>> of being burned as you put it:-)
> 
> Currently, and until HPKP with the strict directive is deployed and
> supported, all HTTPS may be done behind a proxy, and it is invisible to
> the user.

I think the issue of user-visibility is clear. (The answer is not,
but the issue is clear.) But I'm talking about the site and the
consequences of making the proxy visible to the site.

>>> Having this option on the table may allow (in the far future) browsers
>>> to stop scaling back security in the presence of MitM proxies.
>> Yes, current MITM attack boxes are worse. But doing the right
>> thing of exposing the proxy to the web site might well mean
>> giving some sites a choice that requires them to not use
>> HTTP/2.0.
> 
> Again, there is no difference between the versions of HTTP. This
> mechanism would work for both. We can hope that websites will do the
> right thing and find the correct balance between their desire for e2e
> security and their desire to be always available. I can't see online
> retailers such as Amazon blocking proxied connections. Banks might be
> different, but I don't think so.
>> There are real and hard conflicts here between the enterprise
>> desire to scan stuff and the web site desire for e2e security
>> and both need to be properly considered.
>>
> By us, or by the bank?

By the wg. And note that I said "properly considered" which
does not imply that I'm asking that the wg succeed in squaring
the circle. Since we don't seem to have real web sites jumping
in to say what they need, that is definitely tricky.

S.


> 
> Yoav
>

Received on Thursday, 28 November 2013 15:08:46 UTC