Re: channel-bound cookies

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)

3. There are tricky interactions with SPDY.  I believe Dirk has written about those on browserauth.net?  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
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
>