Re: Introducing a Session header...

On Thu, Jul 19, 2012 at 10:36:13PM +0000, Poul-Henning Kamp wrote:
> In message <20120719213630.GA20313@1wt.eu>, Willy Tarreau writes:
> >On Thu, Jul 19, 2012 at 08:48:01PM +0000, Poul-Henning Kamp wrote:
> 
> >I think it would be terribly useful to have a session container in which
> >we can store one or more session identifiers and that load balancers and
> >servers can easily access and manipulate.
> 
> At this point I would like to defer to card-carrying cryptographers,
> because while I think nobody but the client should be allowed to
> define/change the session identifier, in order to shut out spoofing
> of it, I don't trust my own analysis of this question to be definitive.

Yes you're right that if the client builds it by itself, the ID cannot
be injected. However it can still be stolen and reused. But at least
the easiest part of the security failure with cookies would be covered.

> I do think it would be terribly useful if the session-id was client
> originated and contained a anon/specific-authenticated-user bit,
> because that would warn the server about public PCs etc.  So even
> if we don't do the session-id, I think I would advocate that bit
> on its own.

Based on your first point above, I think that the client could build
*part* of the ID. If the client generates a 64-bit random for instance,
it doesn't ensure unicity, which is a server's task, but it saves it
from being injected another ID. So from the server's point of view,
a client could be identified by the couple of (ID1,ID2) where ID1 is
invented by the client and unknown from JS and ID2 is invented by the
server.

We could then even keep cookies as they are for ID2, and just use a
new identifier for ID1. That way we remain compatible with HTTP/1
(important goal) and HTTP/2to1 gateways can pass ID1 into a header
field that the server can use.

If we do something like this, then it is wise to make this ID part
of the protocol, just like the mask is part of the protocol in
websocket without being accessible to the client's stack.

This needs more thinking in my opinion but I think it's worth it.

Willy

Received on Friday, 20 July 2012 05:44:41 UTC