Re: Introducing a Session header...

On 20/07/2012 5:44 p.m., Willy Tarreau 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.

This is where server-side management of its own session steps in.

We have both server and client state to deal with in reality. So far the 
server generating a UUID and sending it to the client (over insecure 
third-party links) has proven insecure to the point of being a joke.

Client-generated session ID, is just a key / salting value. That gives 
us a couple of things:
  1) client can ensure that it is unique (at least relative to any other 
one they generate) over some long time period
  2) client can maintain multiple sessions to the same server simultaneously
  3) client can share session ID between software on their own machine 
(ie several browser tabs, or a browser tab and some independent 
credentials manager software)
  4) client can implement do-not-track by omitting the session ID from 
any request, OR changing it frequently, OR sending some max-age property 
for expiry.
  5) client can "logout" at will by erasing the state associated 
(possibly informing the server, but not necessarily)
  6) limited meaning - simplicity leads to better security through 
easier understanding and thus correct use.
    Making it mean just "here is a reference ID to the data I have on 
you" is simple.


The server can not be expected to rely on that session ID alone as any 
kind of UUID. They need to be able to assign session based on that ID 
*plus* any other information they have available to guarantee the 
uniqueness (client IP, channel number, socket number, UA header, phase 
of the moon, whatever)

  1) server can use it as a salting value to uniquely identify the 
separate client sessions. IFF, the server uses additional data to 
generate the session.
  2) server can track the session across any requests regardless of 
delivery method (relative to what the server tacks on as extra key bits 
for its own end - this also determins/limits theft of session-ID key risk).
  3) middleware can play to its hearts content, altering session IDs to 
new values. They mean nothing but opaque blob to the recipients end, 
worst case is fail-closed if they are used for anything security related.


What we have in abstract is a shared session between client and server, 
where those client/server endpoints may be any number of Federated 
softwares or machines. Each end has its own state, which may or may not 
be conveyed over the links, but for best security only the algorithms 
(.js) and data (.html, .xml, .css, ...) would transfer.

When you get down to the basics of this, it sounds a bit like the OAuth 
Bearer token (login federated between clients) or the Digest nonce 
"session" mode (client-driven ID). PKI abstract design at its finest. 
(Now the card-carrying cryptos will step up and hammer this non-card 
carrying one for obvious mistakes).

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

Exactly. Neither end being required to complete the session, or even to 
inform what its internal session ID key (or even algorithm) is.

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

IMO, we can ignore Cookies as headers for all of this. Sessions in 
Cookies are already largely the provence of web servers and if servers 
and browser roll out the new session they will be able to drop use of 
session-cookie cleanly when Session-ID no longer needs to be 
encapsulated inside one.

Cookies as used for data transfer is a different problem entirely and 
should not be tackled by the creation of a session state semantics. 
Simply removing the credential-like identifier from Cookie will go a 
long way towards clearing up the mess.


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

+1 on both counts.

Amos

Received on Friday, 20 July 2012 06:36:32 UTC