Subject: [http-state] cake and session stealing

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 01:01:45 +0800

So, on consideration for this, I'm not sure that I still understand how this is going to solve the problem that you described.

An attacker that can control where you go (the URL) can equally control what cookies you get.  What am I missing here?

---

From: Adam Barth <[email-masked]>
Date: Mon, 26 Jul 2010 23:25:02 +0200

> An attacker that can control where you go (the URL) can equally control what cookies you get.  What am I missing here?

Cake is never sent from the server to the client.  It's only ever sent
from the client to the server, and then only over TLS.  An active
network attacker cannot interact with the cake for HTTPS.  (Of course,
he can steal the HTTP cake, but there's no way to defend HTTP from
network attackers anyway.)

Adam

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 15:13:15 +0800

> > An attacker that can control where you go (the URL) can equally
> control what cookies you get.  What am I missing here?
> 

That's where my concern arose.  An attacker that is playing MITM can simply use their own cake.  Are we basically looking for something with basically "leap of faith" characteristics?

I suppose that it is an advantage that the attacker needs to arrange for an attack by playing MITM for all requests, which requires a degree more premeditation.  I'm not convinced that it's significantly better than the mechanisms we already have.

--Martin

---

From: Adam Barth <[email-masked]>
Date: Tue, 27 Jul 2010 10:17:45 +0200

> That's where my concern arose.  An attacker that is playing MITM can simply use their own cake.  Are we basically looking for something with basically "leap of faith" characteristics?

There's no leap of faith.  How does the MITM alter the cake in the TLS tunnel?

> I suppose that it is an advantage that the attacker needs to arrange for an attack by playing MITM for all requests, which requires a degree more premeditation.  I'm not convinced that it's signifi…

The protocol is designed to resist MITM attacks.  Cookies cannot.  The
security property are demonstrably stronger.

Adam

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 16:27:47 +0800

> > That's where my concern arose.  An attacker that is playing MITM can
> simply use their own cake.  Are we basically looking for something with
> basically "leap of faith" characteristics?
> 

We were talking about the step from unsecured TCP to TLS.  The problem was that state accumulated prior to this step is attributed to the client.

Cake ensures that the same client can be identified.

If you have a MITM, then you can do this:

Accept the client cake C and forward their requests on using a different cake F.  State A is established against cake F.

In parallel, establish desired state against cake C.  Then when the client hops to a secured connection, they start using your desired state.

The only solution I see to this is to treat anything that comes in on an unsecured connection as suspect.  Online shopping services do this - you build a cart, but they confirm again on the secured part (sometimes several times).

--Martin

---

From: Adam Barth <[email-masked]>
Date: Tue, 27 Jul 2010 10:41:18 +0200

> We were talking about the step from unsecured TCP to TLS.  The problem was that state accumulated prior to this step is attributed to the client.

There is no insecure step from TCP to TLS.

> In parallel, establish desired state against cake C.  Then when the client hops to a secured connection, they start using your desired state.

There's a separate cake for every origin.  In particular, there's a
separate cake for http://bank.com and https://bank.com.  There is no
way for the attacker to learn or overwrite the cake for
https://bank.com.  That means whatever stateful interaction the user
has with the server on https://bank.com is protected from the
attacker.

Of course, the attacker can have their own stateful interaction with
https://bank.com, but that will be with their own cake and won't
interfere with the user's interaction with https://bank.com.

> The only solution I see to this is to treat anything that comes in on an unsecured connection as suspect.  Online shopping services do this - you build a cart, but they confirm again on the secured…

If a site uses http, there's nothing we can do to protect them from a
MITM attacker.  We're interested in protecting https sites from MITM
attackers.

Adam

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 17:01:20 +0800

> has with the server on https://bank.com is protected from the

When you talked about this in the meeting, you talked about the step from unsecured http to TLS secured http.  I guess I misunderstood what you were trying to achieve.

> > The only solution I see to this is to treat anything that comes in on
> an unsecured connection as suspect.  Online shopping services do this -
> you build a cart, but they confirm again on the secured part (sometimes
> several times).
> 

OK, I'm still trying to come to terms with the problem that you are solving.  The problem is that you are looking for a way to have session state that is not subject to the fragility of cookies.  A server wants to be able to correlate requests from the same client because the _server_ is storing state.

That doesn't scale particularly well, which was Mark's comment.  

Here's another idea: hide the state in URIs.  Rely on the fact that the URIs are only seen by the one client.  No protocol changes there.

--Martin

BTW, cake provides less capability than a cookie.  (That's not necessarily a bad thing.)  It's more of a wafer or water cracker.

---

From: Adam Barth <[email-masked]>
Date: Tue, 27 Jul 2010 11:08:50 +0200

> When you talked about this in the meeting, you talked about the step from unsecured http to TLS secured http.  I guess I misunderstood what you were trying to achieve.

You can't hope to protect that scenario from an active network
attacker.  We're interested in protecting against a web attacker
(i.e., an attacker who controls a web site, not a MITM).  I suspect
that the notion of a web attacker is an alien concept to many folks at
the IETF, but it's a very common notion in web security.

For a rigorous definition of a web attacker, please see:

http://www.adambarth.com/papers/2010/akhawe-barth-lam-mitchell-song.pdf

> OK, I'm still trying to come to terms with the problem that you are solving.  The problem is that you are looking for a way to have session state that is not subject to the fragility of cookies.  A…

Yes.

> That doesn't scale particularly well, which was Mark's comment.

That might be his opinion, but that's how virtual every web site works.

> Here's another idea: hide the state in URIs.  Rely on the fact that the URIs are only seen by the one client.  No protocol changes there.

Storing state in URLs doesn't work very well for two reasons:

1) URLs are not secret.  They leak all the time (e.g., in Referer, by
copy paste, etc.)
2) URLs have even less integrity than cookies.  Cookies can be
overwritten by a network attacker, but URLs can be overwritten by just
a web attacker.

Various folks (e.g., PHP) tried state storage in URLs and it was an
unmitigated disaster.

Adam

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 17:23:05 +0800

OK, thanks Adam.

I'm happy.  I'll say what (I think) EKR did: it's not a terrible idea.  It could work.

Obviously, the tracking thing needs a bit more consideration, and the self-signed cert option (which sounds like a cool idea) will require server changes, but those are secondary problems.

--Martin

---

From: Adam Barth <[email-masked]>
Date: Tue, 27 Jul 2010 11:27:24 +0200

Thanks.  I'll put together an I-D that explains the whole thing from
soup to nuts.

Adam