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
>
>
>
>
>
>
>
>
>
>
>
>