Re: Introducing a Session header...

On 20/07/2012 7:02 p.m., Willy Tarreau wrote:
> On Fri, Jul 20, 2012 at 06:35:54PM +1200, Amos Jeffries wrote:
>> Client-generated session ID, is just a key / salting value. That gives
>> us a couple of things:
> I agree, this is equivalent to salting.
>
>>   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.
> OK.
>
>> 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)
> Warning when you're saying this, some of these info are neither stable
> nor unique to the client, they provide low value when building an ID.

That is intentional.
The server determines these values, so has control over how much it 
trusts the client, indeed how it defines "client", for portability of 
the session state at the server end. ie whether to protect against 
replay attacks, mobility support, future P2P facebook network.

That bank you work for would likey want to prevent clients moving 
country within a session. Google search may not care.

All the benefits we currently enjoy with server-sessions are retained. 
Along with this extra security from salting to uniquey identify the 
client end-point.



>
>>   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.
> It's not as simple : if we want it to be simple for both ends, ideally
> a fixed-length well-defined ID is fine. However its use will be too
> limited (middleware cannot rely only on "learning" IDs, they need to
> put deterministic information there such as server identifiers when
> performing load balancing between multiple DCs, DMZ, ...).

Why can't server identifiers be associated with learnt IDs? What is 
learning apart from the LB playing server with its session-state 
containing a pointer at another server which does the donkeys work 
(using the same session-ID, OR a new one from the LB generated for the 
unique client).


> If we have a variable-sized ID that intermediaries can fiddle with,
> then it's harder to put that in the protocol and we risk seeing it
> degraded as cookies to put whatever in them.
>
> Maybe we need a specific part for routing information, but I'm really
> not convinced this is needed. I think in fact that the client-generated
> ID should be fix-sized and always present, and that the server-generated
> part could be variable with a limited size so that it is not abused
> anymore.

To prevent mis-use the way cookies were I agree.

Do we have any data on how many systems are abusing session-cookie IDs 
and the equivalent to encode data over the wire?
Given that we are not burning Cookie at the gateway (using it for data 
transfer is easier), what is the actual risk here?

>
>> 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,
> Wait a minute, a few times in this thread I felt like there was an issue
> here, it's important to keep in mind that there is not a single-end on the
> server side. Servers are often split between multiple machines, multiple
> DMZ, multiple areas, multiple DCs for a single client session, and with
> various possible paths between them without the client ever being aware
> of it. It's important because there is not an "own state" as called here,
> but a global state made of many independant states.

Understood. I have been working from that viewpoint.
IFF the servers federate behind an LB they have the same shared session 
state - no problems with rleation to teh client and client connectivity 
(lag maybe but not HTTP protocol related).
If not, they have different state. They can all safely receive the same 
client session-ID since it is opaque to them, and no data is sent back 
to the client be receiving it. The servers responding with different 
session-ID makes it clear to the client when and where context shifting 
of the state at its end required.

Where I stop in this rabbit hole is at client determination of what to 
do when its got state and the servers its talking too keep changing. I'm 
hoping the browser people might be able to shed a bit of light that we 
can continue a bit further there.

> (...)
>>> 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.
> Only when the session-id is able to convey as much information as is
> needed to route the request to its target. Right now cookies are used
> *a lot* for this. I know some places where there are up to 6 layers
> of server farms with multiple possible paths between them (think many
> portals for similar access to same information), and the only way to
> know where to pass through is to use the information inserted by LBs
> into cookies. To completely get rid of cookies we need to be able to
> store this routing information somewhere else (I would love this, so
> that we don't have to deal with this horrible cookie header anymore).
> But this is not a small issue to deal with.

That is our discussions on where to take network-friendly request-ID 
field come in. Being separate from end-to-end session it provides enough 
hop-by-hop state and multiple request linkages to form a stateful flow 
out of a hierarchy with stateless input.


>
>> Cookies as used for data transfer is a different problem entirely and
>> should not be tackled by the creation of a session state semantics.
> Cookies are even more generic, they're just a copy of opaque data the
> server needs when the client gets back. Originally it was just a way
> to find the pointer to the session (which is routing information as
> well after all). But they were completely abused to carry anything
> everywhere and the first issue is that JS has access to them.

Aye. But to kill them we have to pull out their utility and provide 
easier tools for their users to work with. Killing them with efficiency 
as it were. One slice at a time.

Amos

Received on Friday, 20 July 2012 08:21:24 UTC