On Jul 11, 2013, at 7:51 PM, Trevor Perrin <[email protected]<mailto:[email protected]>> wrote:
But even if we restrict our solution to HTTPS, I don't see how ChannelID helps a problem like the BEAST and CRIME attacks. In both cases, the issue is the scoping of cookie use. An attacker's web page or script can cause the UA to send requests of the attacker's choosing to a server. This has nothing to do with TLS - this in an HTTP behavior. ChannelID solves this problem. The goal of BEAST, CRIME, or other forms of cookie theft is to steal a *usable* cookie. With ChannelID, the channel-bound cookie that an attacker might steal is unusable. True, but I believe that the fact that attackers are able to get the UA to send arbitrary requests to a server and have them bless this request with their cookie is bad enough. I can demonstrate this with a real world example. This is from a real firewall appliance. I won't mention names, except to say that it is not from my company (otherwise I would be too embarrassed to post this to a public mailing list. This firewall had a web-based management interface protected with HTTPS. The pages would have all kinds of buttons, each button had a name pretty similar to the text on the button, and clicking the buttons would cause a GET request like this: GET /mainpage.html?button=something,field1="", field2="". So I recorded some traffic (it was HTTPS, so I had to use a browser add-on to record it), and got this: * GET /maingage.html?button=shutdown caused the firewall to power-off. * GET /mainpage.html?button=unload caused the firewall to unload policy, so that it didn't enforce policy or do IPsec or anything a router wouldn't do. So I tried opening another browser tab, and loading an HTML document that said <img src="https://myfw/mainpage.html?button=shutdown";> Yes, the firewall powered down, and if I had used "unload" instead of "shutdown" that would be the end of enforcing a security policy. Now, granted, this is epic levels of cluelessness. But Channel-bound cookies don't save the administrator of this firewall. Only changing the rules around "blessing" requests with cookies can help. I'm all in favor of binding to TLS or MAC-ing the requests, but I think we need those in addition to making cookie behavior secure, not instead of. Having re-read draft-balfanz, that draft only has a TLS extension. Section 7.1 is only an example of how that extension can be used. If we really wanted a channel-bound cookie, we'd need a different document that specified channel-bound cookies. So we'd need someone two write such a draft. Yoav
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
