W3C home > Mailing lists > Public > public-web-security@w3.org > March 2012

Re: channel-bound cookies

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 14 Mar 2012 19:19:39 -0700
Message-ID: <CAJE5ia_B7Ntz8p=7iTU66=oPsets50X=Q3mytZh2zPJmG3HKdw@mail.gmail.com>
To: Enduro USA Tour <endurousatour@yahoo.com>
Cc: Dirk Balfanz <balfanz@google.com>, Mike Hanson <mhanson@mozilla.com>, "Richard L. Barnes" <rbarnes@bbn.com>, "public-web-security@w3.org" <public-web-security@w3.org>
I suspect TLS-OBC makes sense only for user agents that both use TLS
and have a notion of an origin (in the RFC 6454 sense).  SSH doesn't
use TLS, and I don't think WS-Trust has a notion of an origin.

Adam


On Wed, Mar 14, 2012 at 7:15 PM, Enduro USA Tour
<endurousatour@yahoo.com> wrote:
> Are web browsers the primary beneficiary of TLS-OBC?  Or could other
> applications benefit from this as well?
>
> For example, does it make sense for SSH v1 or v2, or clients that implement
> WS-Trust to implement TLS-OBC as well?
>
> ________________________________
> From: Dirk Balfanz <balfanz@google.com>
> To: Mike Hanson <mhanson@mozilla.com>
> Cc: Enduro USA Tour <endurousatour@yahoo.com>; Richard L. Barnes
> <rbarnes@bbn.com>; "public-web-security@w3.org" <public-web-security@w3.org>
> Sent: Tuesday, March 13, 2012 1:00 PM
> Subject: Re: channel-bound cookies
>
>
>
> On Tue, Mar 13, 2012 at 8:29 AM, Mike Hanson <mhanson@mozilla.com> wrote:
>
> There are a number of issues that need to be considered for TLS-OBC; I'll
> highlight a couple here that I'm aware of.
>
> 1. Some SSL handshake logic may need to be modified slightly;
> see https://bugzilla.mozilla.org/show_bug.cgi?id=681839 for technical
> discussion.
>
> 2. There are potential privacy considerations; in particular if the unique
> client certificate is sent in cleartext before the negotiation of the master
> secret, a passive network observer may be able to uniquely identify a client
> machine.  The attacker would already have the client's IP address, so this
> isn't a huge problem if the certificate is regenerated on an IP address
> change, but that would nullify much of the authentication benefit.  A
> proposal to allow a client certificate to be sent after the master secret
> negotiation has been made. (can't find the bug right now, sorry)
>
>
> One proposal how this could be done is
> here: http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts
>
>
>
> 3. There are tricky interactions with SPDY.  I believe Dirk has written
> about those on browserauth.net?
>
>
> I haven't. I should, though. I'll get on it. :-)
>
> Dirk.
>
>
>  In general, client certificates cause degradation of the connection-reuse
> properties of SPDY.  See https://bugzilla.mozilla.org/show_bug.cgi?id=528288
> for discussion (search for "client certificate", it's long)
>
> 4. SSL terminators and SSL-aware load balancers may not be prepared for the
> volume of client certificates that a TLS-OBC deployment would generate; this
> is more of a configuration issue since a host would need to explicitly
> request OBC and many SSL terminators would have to be recoded to request the
> extension in the first place.
>
> 5. The (already-problematic) user interactions around end-user client
> certificates would have to take priority over the (automatic) generation of
> an OBC certificate.  If done properly these would live in two different
> worlds.  We would need to agree on a standard set of user interactions to
> clear brower certificates - the generation expectation is that "clearing
> cookies" should also clear the certificates, since users have already been
> trained to use this gesture.
>
>
> -m
>
>
> On Mar 12, 2012, at 6:18 PM, Enduro USA Tour wrote:
>
> TLS-OBC originally threw me when I skimmed through it and saw "Browser
> Certificates".  Thank goodness this proposal requires for no prompting of
> the end-user, and supports self-signed certs in absence of any other
> certificate.
>
> Well I'm almost sold on TLS-OBC, it makes sense and is a better solution
> overall than the Origin Cookies, although both solve my need.  Thanks for
> the additional links to www.browserauth.net; it's quite helpful.
>
>  Are there any compatibility issues with TLS-OBC and existing Browser
> Certificate deployments that are in the field today?
>
> ________________________________
> From: Dirk Balfanz <balfanz@google.com>
> To: Mike Hanson <mhanson@mozilla.com>
> Cc: Richard L. Barnes <rbarnes@bbn.com>; Enduro USA Tour
> <endurousatour@yahoo.com>; "public-web-security@w3.org"
> <public-web-security@w3.org>
> Sent: Monday, March 12, 2012 3:02 PM
> Subject: Re: channel-bound cookies
>
> What Mike said. :-)
>
> Also, note that somewhat counter-intuitively, channel-bound cookies protect
> against many related-domain attacks even if the client cert that they are
> bound to has broader scope than a web origin.
>
> Imagine, for a moment, that a user-agent creates a single self-signed
> certificate that it uses as a TLS client cert for all connections to all
> servers (not a good idea in terms of privacy, but follow me along for this
> thought experiment). The servers then set cookies on their respective
> top-level domains, but channel-bind them to the user-agent's one-and-only
> client cert.
>
> So, let's say that an app app.heroku.com sets a (channel-bound) cookie on my
> browser for domain .heroku.com, and that there is an attacker on
> attacker.heroku.com. One attack we might be concerned about is that the
> attacker simply harvests the .heroku.com cookie from my browser by luring me
> to attacker.heroku.com. They won't be able to actually _use_ the cookie,
> however, because the cookie is channel-bound to _my_ browser's client cert,
> not to the attacker's client cert.
>
> Another attack we might be concerned about is that attacker.heroku.com
> _sets_ an .heroku.com cookie on my user agent in order to make me log into
> app.heroku.com as himself. Again, assuming that the only way the attacker
> can obtain the cookies is by getting them from app.heroku.com, this means
> that the cookies he has at his disposal will be channel-bound to _his_
> client cert, not to my client cert - thus when my browser sends them to
> app.heroku.com they won't be valid.
>
> The TLS-OBC proposal, of course, assumes more fine-grained "scopes" for the
> client certificates. The reason for that, however, is purely to prevent
> tracking across unrelated domains. Related-domain attacks are already
> mitigated even if we used coarse-grained client certificates and
> coarse-grained (i.e., domain) cookies. I, at least, found this a little
> counter-intuitive at first, since the other proposed defense it to forbid
> coarse-grained cookies altogether and use origin cookies instead.
>
> Dirk.
>
> On Mon, Mar 12, 2012 at 10:03 AM, Mike Hanson <mhanson@mozilla.com> wrote:
>
> I would also note that Dirk Balfanz (the author of that draft) has written a
> more verbose / user-friendly explanation of Origin Bound Certificates and
> Channel Bound Cookies, here:
> http://www.browserauth.net/channel-bound-cookies
>
> -mh
> --
> Michael Hanson
> Mozilla Labs
>
>
>
> On Mar 12, 2012, at 7:25 AM, Richard L. Barnes wrote:
>
> There's some related work proposed in the IETF TLS working group.  The idea
> there is to bind cookies to TLS client certificates, so as long as the
> private key corresponding to the cert is only on one machine, the cookie can
> only be used on one machine.
> <http://tools.ietf.org/html/draft-balfanz-tls-obc-01>
>
> Of course, you could also just associate cookies with a client IP addresses
> on the server side...
>
>
>
> On Mar 11, 2012, at 11:53 AM, Enduro USA Tour wrote:
>
>
> I'm an independent security researcher and am interested in addressing
>
> Related Domain Cookie Attacks.  See these links for more info on the
>
> problem:
>
>
> http://security.stackexchange.com/q/12412/396  and
>
> http://stackoverflow.com/q/9636857/328397
>
>
> I would like to pitch a few approaches on addressing this vulnerability,
>
> but before I do that, is anyone aware of a solution that binds a cookie to
>
> a host, limiting the ability of the attacker to transfer or replay it on a
>
> different host?  That is essentially the vulnerability that is described in
>
> the links above.
>
>
> Before I pitch my solution, I'd like to see if you agree that the issue is
>
> relevant to this group, and of importance.
>
>
> Thanks for your time!
>
>
> Chris Lamont Mankowski
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Received on Thursday, 15 March 2012 02:20:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 15 March 2012 02:20:40 GMT