Re: [http-state] cake and session stealing

["Thomson, Martin" <[e-mail]>]

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

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

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.