Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00
On Wed, Jul 10, 2013 at 5:39 PM, Nico Williams n...@cryptonector.comwrote: Also: despite mentioning a few proposals, there's no mention of ChannelID / Channel-bound cookies [3]. ChannelID seems to solve these problems, seems more polished than other proposals, and apparently is being experimentally deployed (see Chrome | Preferences | Cookies and site data | google.com or gmail.com). There's definitely mention of channel binding. Channel bound cookies used over HTTPS would meet the requirements of this spec, except for the CRIME/BEAST resistance part. I'm not sure that we should mandate CRIME/BEAST resistance -- TLS should arguably be able to resist such attacks. But it will take a long time to deploy TLS that does, and that's what makes it appealing to have CRIME/BEAST resistance in the session continuation protocol. We should not be mandating resistance to particular attacks already solved. But we should be mandating a change in the authentication design. The point is that the security of the authentication tokens should not be compromised even if the confidentiality scheme fails. Confidentiality should be built on authentication, not the other way round as using bearer tokens forces us to do. CRIME/BEAST would be a serious problem in any case and I find it amazing that we still have people pushing header compression schemes even now. And thats not the end of the problems either. The 'make it unsafe, we want speed' crowd is currently looking at using HTTP over UDP for bulk transport (not CoAP, web browsing) so expect DoS problems to get much worse. The lesson we should be drawing from CRIME/BEAST is that the web browser developers don't actually give a damn about security. There are security people working for them but don't be fooled, the people who manage those products don't consider security a priority or else we would have revocation checking in SSL clients that is meaningful and many other things. The KGB and the NSA both have doctrines that say that a system must be robust in the case of failure of a cryptographic protocol. We have to adopt the same sort of approach because modern Web browsers are ridiculously complex and getting more so. There is nobody who can claim to understand and be able to vouch for the security of the interactions between all the components. CRIME is a consequence of two design decisions taken without care for security: header compression and active code. Those two decisions are not going to be the last. Since we can't understand the consequences of those interactions our only viable design approach is to design the session continuation scheme so that the security of the authentication secrets ONLY depends on things we can count on. - Will you be willing to review the problem statement? - Will you be willing to read multiple solution proposals to help the working group choose? - Will you be willing to review the solution document? I'd be more interested in websec taking this on if someone could argue why ChannelID is *not* the right solution, and had some ideas how to do better. See above. Nico -- ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec -- Website: http://hallambaker.com/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00
On Jul 11, 2013, at 12:32 AM, Trevor Perrin tr...@trevp.netmailto:tr...@trevp.net wrote: ChannelID seems to solve these problems, seems more polished than other proposals, and apparently is being experimentally deployed (see Chrome | Preferences | Cookies and site data | google.comhttp://google.com/ or gmail.comhttp://gmail.com/). - Will you be willing to review the problem statement? - Will you be willing to read multiple solution proposals to help the working group choose? - Will you be willing to review the solution document? I'd be more interested in websec taking this on if someone could argue why ChannelID is *not* the right solution, and had some ideas how to do better. Hi Trevor [wearing no hats] ChannelID is a TLS-layer extension. As such, it does nothing for HTTP. OTOH a proposal that hashes some header fields with a secret value works with or without TLS. 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. As it is, if I visit a website that has img src=https://mail.google.com/gaah; my UA is going to send a request to mail.google.comhttp://mail.google.com for gaah, and that request is going to have my cookie. I don't see what ChannelID adds here. With channel-bound cookies (section 7.1) my UA will send the same request to mail.google.comhttp://mail.google.com, but with a channel-bound cookie. But since it's my valid channel, the server will accept it just the same. What we need, IMO, is a new cookie with new rules, such as that cookies will be indexed by origin and refer(r)er so that my UA would use different cookies for requests stemming from pages from google and requests initiated by pages and scripts from other origins. This kind of rule change is more important than either the crypto binding or the request hashing. Yoav ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00
On Thu, Jul 11, 2013 at 5:50 AM, Yoav Nir y...@checkpoint.com wrote: On Jul 11, 2013, at 12:32 AM, Trevor Perrin tr...@trevp.net wrote: ChannelID seems to solve these problems, seems more polished than other proposals, and apparently is being experimentally deployed (see Chrome | Preferences | Cookies and site data | google.com or gmail.com). - Will you be willing to review the problem statement? - Will you be willing to read multiple solution proposals to help the working group choose? - Will you be willing to review the solution document? I'd be more interested in websec taking this on if someone could argue why ChannelID is *not* the right solution, and had some ideas how to do better. Hi Trevor [wearing no hats] ChannelID is a TLS-layer extension. As such, it does nothing for HTTP. That's true, but is it important? If a site can't be bothered to deploy TLS, is it going to deploy a new session management mechanism? The security gain of improving cookies without deploying TLS seems small - it might protect cookies at http://example.com; from someone who hacks http://test.example.com;, but that's about it. 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. What we need, IMO, is a new cookie with new rules, such as that cookies will be indexed by origin and refer(r)er so that my UA would use different cookies for requests stemming from pages from google and requests initiated by pages and scripts from other origins. This kind of rule change is more important than either the crypto binding or the request hashing. Deriving new cookie values based on where the cookie originated and where it is being sent is one approach. But making cookies sent to a particular client untransferable to other clients seems equally valid, and is simpler if you can rely on something (eg ChannelID) to securely differentiate clients. Trevor ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00
On Jul 11, 2013, at 7:51 PM, Trevor Perrin tr...@trevp.netmailto:tr...@trevp.net 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 websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00
On 07/11/2013 02:41 PM, Yoav Nir wrote: * 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. these are indeed epic levels of cluelessness. at the very least the authors of such an appliance need to learn the distinction between POST and GET, which would prevent your attack. If the authors aren't capable of making this distinction (which has been around for nearly 20 years), and they don't use widely-known measures for CSRF protection (itself coming up on 10 years old, i think) when they have users who enable javascript, i strongly doubt they'll deploy any sort of fancy session continuation even if we specify it perfectly. I'm not sure this sort of example is a reasonable argument for developing any new standard technical measures, since by definition the culprits here are not making use of standard technical measures. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00
On Thu, Jul 11, 2013 at 1:58 PM, Nico Williams n...@cryptonector.comwrote: At any rate, I don't think we should do anything to exclude channel bound cookies (at least not yet, not without much more discussion as to why) as a candidate session continuation protocol. I have given reasons why I think it shouldn't be the only candidate at this time, That's fair, but I do think ChannelID sets a high standard. It's clear, simple and can strongly protect cookies. The proposals from this WG seem much more complicated [1,2], and it's hard to tell whether they resist attacks such as: - Session forcing, where a MITM attacker transfer a session to the victim client, thus logging the victim into the attacker's account. - Session stealing, where an attacker observes or receives a victim client's request, and then makes the same request himself (perhaps just replaying it, perhaps modifying it). Trevor [1] http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00 [2] http://tools.ietf.org/html/draft-hallambaker-httpsession-01 ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00
On Sun, Jul 7, 2013 at 10:37 PM, Yoav Nir y...@checkpoint.com wrote: Hi all This has been submitted with a websec filename, but note that this is not (yet) on our charter. At the Orlando meeting, we discussed some of the security issues with keeping HTTP sessions using cookies. There was consensus in the room that this is a problem that needs solving. Nicolas Williams, Phillip Hallam-Baker, and Yaron Sheffer volunteered to write a problem statement, and this is it. The message we got from our AD is that first we should show that the working group has the time and energy to work on solving this problem, and then we can add this to our charter. So please have a look and this document, and answer the following: - Is this a good starting point for the problem statement? Hmm, it's surprising there's no discussion of cookie scoping problems like: - cookie stealing via MITM-created subdomains [1], or - cookie forcing via attacker-controlled sibling or cousin domains [2] These attacks seems particularly relevant to this WG, since they can subvert hostname-specified security like HSTS or HPKP. Also: despite mentioning a few proposals, there's no mention of ChannelID / Channel-bound cookies [3]. ChannelID seems to solve these problems, seems more polished than other proposals, and apparently is being experimentally deployed (see Chrome | Preferences | Cookies and site data | google.com or gmail.com). - Will you be willing to review the problem statement? - Will you be willing to read multiple solution proposals to help the working group choose? - Will you be willing to review the solution document? I'd be more interested in websec taking this on if someone could argue why ChannelID is *not* the right solution, and had some ideas how to do better. Trevor [1] http://tools.ietf.org/html/rfc6265 Section 4.1.2.3 WARNING https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies Scope http://tools.ietf.org/html/rfc6797 Section 14.4 [2] http://tools.ietf.org/html/rfc6265 Sections 4.1.2.5 and 8.6 http://scarybeastsecurity.blogspot.com/2008/11/cookie-forcing.html https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies Overwriting cookies [3] http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
