Re: Yet another trusted proxy suggestion

>From what I understand, it's well known in banks that there are MITM 
proxies, and so TLS is not considered to equal security.

So I agree with Yoav that a bank that truly embraces a policy that it 
shall be impossible to snoop on this data would need to block internet 
banking or use client certs.

The turn a blind eye because it's not explicitly flagged in a http 
request approach is not really defensible as the banks cannot claim 
ignorance.

I think in the end the banks would prefer to know, and would come to 
pragmatic arrangements with clients that minimise client and bank IT 
support pain.

e.g. have a setting in the bank user settings about allowing use via 
particular proxies etc.  So that customers can do banking inside their 
real-world environments, but not be vulnerable to any proxy anywhere.

Adrien

------ Original Message ------
From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
To: "Yoav Nir" <synp71@live.com>; "HTTP Group" <ietf-http-wg@w3.org>
Sent: 29/11/2013 4:08:22 a.m.
Subject: 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 19:32:51 UTC