- From: Yoav Nir <synp71@live.com>
- Date: Thu, 28 Nov 2013 13:15:23 +0200
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, HTTP Group <ietf-http-wg@w3.org>
- Message-ID: <BLU0-SMTP3954CEB94B75752A7028591B1EE0@phx.gbl>
On 28/11/13 11:37 AM, Stephen Farrell wrote: > Hi Yoav, > > On 11/28/2013 07:51 AM, Yoav Nir wrote: >> I'd love to hear more comments on this. If there's interest I could >> write it up in a draft, but having been burned twice, I'd like to know >> there's interest first. > I think your caution is wise. > > Let me ask one of the possibly many hard questions: say I'm a bank, > wouldn't the result of your proposal be that I'd not be able to > turn on HTTP/2.0 because e.g. one of my regulators somewhere would > forbid me agreeing to exposing my customer's credentials to one > or more such proxies? First, nothing in my proposal (except maybe the pushed resource, which could be easily replaced with a pulled resource) is unique to HTTP/2. This is equally applicable to HTTP/1. Second, there are now MitM proxies that expose customers' credentials. To defend against them, the bank has several options: * Deploy HPKP with the "strict" directive. Can't say that's widely deployed, although I'm told it is implemented in Chrome. You have multiple ways of bricking your site if you're not careful with this, so it's WebSec's version of five finger fillet. But banks can afford to do it correctly. * Deploy client certificates for users. This defeats all TLS proxies, unless you come up with a proxy that somehow gets the user's private key. It doesn't get any more "trusted" than that. Very few banks do this. If they have a policy like you suggested, and they don't use the above measures, they're not enforcing their policy now. 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. > I'd love if we had a real bank asking that question btw, since > I'm just guessing, and am not and never have been a bank:-) But > we don't seem to have anyone like that on the list asking. I don't think it counts, but I did interview at a bank before going to work at Check Point, although that was for a systems administration job, not a security job. Banks are into cost cutting, and the way to get costs lower is to avoid people coming into the bank branch and occupying some of the teller's time. To that end, they will allow you to connect with a browser, a phone, a kiosk, pretty much anywhere. They'll weigh the cost of fraud from HTTPS proxies against the cost of losing customers to a more lenient bank to choose their policy. That of course depends on country and regulations, because different jurisdictions have different proportions of the cost of fraud falling to the bank and to the customer. Banks might have policies like refusing to perform high-value transactions through a proxy. This doesn't protect regular credentials, but it could protect one-time passwords and such. But again, I don't work for a bank either and never have. I still think allowing them to enforce a policy is better than what we have today. Having this option on the table may allow (in the far future) browsers to stop scaling back security in the presence of MitM proxies. Yoav
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 28 November 2013 11:15:55 UTC