Re: Introducing a Session header...

We're basically reinventing parts of the TLS handshake.

I don't want this to turn into TLS vs not TLS, just pointing out that
generating a shared nonce securely is something we already know how to do.

-=R
On Jul 19, 2012 10:47 PM, "Willy Tarreau" <w@1wt.eu> wrote:

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