Re: [http-state] Origin cookies

[Adam Barth <[e-mail]>]

On Sun, Mar 6, 2011 at 11:55 PM, tho <[e-mail]> wrote:
> On Mar 6, 2011, at 2:46 AM, Adam Barth wrote:
>> Hi http-state,
>>
>> Now that we're done with phase 1, I've updated my phase 2 proposal:
>>
>> http://www.ietf.org/id/draft-abarth-cake-01.txt
>
> it's not clear how the stated confidentiality and integrity properties are achieved.
>
> Could you please elaborate a bit about that ?

Sure.  Let's assume we're dealing with an active network attacker, as
defined in Section 2 of this paper:

http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

In particular, we've got an honest user (Alice) using a
standards-compliant web browser to visit an honest site (example.com)
that's entirely hosted over HTTPS, but the user is using an untrusted
network that's completely controlled by an attacker.

In this setting, the attacker controls all HTTP responses but only
HTTPS responses from host names owned by the attacker (for which the
attacker can purchase a certificate).  Also, in this model, the user
never agrees to whitelist certificate errors.

Confidentiality of Origin cookies is achieved the same way for Secure
cookies.  Namely, an Origin cookie set by https://example.com in
Alice's browser will only be sent over a TLS connection to
example.com.

Integrity of Origin cookies is achieved as follows.  Suppose the
example.com receives an Origin-Cookie header with a particular value
over a TLS connection.  If the header was sent by Alice's browser,
then the server can reason that the cookie was set by its own origin.
(Note: The same cannot be said of Secure cookies.)

Adam