Jump to content

HTTP sessions: Client vs Server side

Add links
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by DStoykov (talk | contribs) at 21:09, 22 September 2006 (Active Server Pages). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Usually, web sites/applications which use dynamic content generation techniques (PHP, ASP, JSP, etc.) need to associate state variables with clients that request service from them.

HTTP itself is stateless, so HTTP cookies are used to add more complex application-level sessions to the basic request/response protocol.

Upon request, HTTP clients can receive a header field named Set-Cookie along with the response, which contains a sequence of bytes to be stored locally (i.e. on the client).

It is then up to the client to add a header containing the previously memorised information upon successive requests to the same server.

Server side sessions

Since cookies are sent unencrypted and often variables associated with clients need to remain confidential, their only purpose needs to be to store a unique identifier of the client and to associate it with a file, DB entry or more in general a block of data containing the session state. This state-handling method is more commonly known as "server-side session".

Server-side sessions are handy and efficient, but can become difficult to handle in conjunction with load-balancing/high-availability systems and are not usable at all in embedded systems with no storage.

The load-balancing problem can be solved by using a shared storage or by applying forced peering between each client and a single server in the cluster, hence compromising system efficiency and load distribution.

A method of using server-side sessions in systems without mass-storage is to reserve a portion of RAM to storage of session data. This method is applicable to situations with a limited number of clients (e.g. router or access point with infrequent or disallowed access to more then one client at a time).

In the two above-mentioned scenarios, usage of client-side sessions would provide net advantages over server-side sessions: in the first case by reducing the limitations applied to load-balancing algorithms (which usually translates to load distribution optimisation), and in the second case by allowing usage of sessions in web applications which cannot make use of RAM or disk space for storage due to necessity or choice.

Client side sessions

Client-side sessions use Cookies and cryptographic techniques to transparently use sessions in scenarios such as those mentioned above.

How they work

At the end of execution of a dynamic web page, the value of session variables is calculated, compressed and transmitted to the client via a Cookie. At this stage the state resides entirely and only on the client file system (or RAM).

For each successive request, once it has been decompressed, the Cookie is forwarded to the server which uses it to "remember" the state of the application on that specific client.

Although this mechanism may suffice in some contexts, it cannot be adopted where confidentiality and integrity are necessary. If one wishes to use client-side sessions instead of server-side sessions, the following must be guaranteed:

  1. confidentiality (optional): nothing apart from the server should access session information
  2. data integrity: nothing apart from the server should manipulate session data (accidentally or maliciously)
  3. authenticity: nothing apart from the server should be able to generate valid sessions

In order to accomplish this, the session data needs to be encrypted before being memorised on the client and modification of such information by any other party should be prevented via other cryptographic means.

An open-source implementation

The only implementation of client-side sessions publicly available, which provides the aforementioned features, is KLone [1].

KLone implements the above features [2] by using standard (FIPS, ANSI, IETF) cryptographic algorithms, which are considered state-of-the-art in terms of robustness and are well exposed due to their diffusion. In particular, KLone obtains confidentiality by using a symmetric cryptography algorithm (AES-256) with a key which is generated at run-time. Integrity and authenticity of Cookies is achieved by using a keyed-hash algorithm (HMAC), which has been shown to be safe from collisions found in lower-level hash functions (e.g. SHA1, MD5) [3].

Another piece of information (other than the Cookie) which needs to be associated with a session is the last modification time. It is required in order to handle session expiry and, even though confidentiality is not necessary, it should still be protected against modification of session duration. This attribute can be used as a foundation to build countermeasures against replay attacks in both client-side and server-side sessions.

Getting to the crux of the matter, each session makes use of 4 Cookies:

  1. klone_sid: unique session identifier, also known as SID (used also for normal server-side sessions)
  2. KL1_CLISES_ATIME: last access time - timestamp representing the time at which the session was last accessed/modified
  3. KL1_CLISES_DATA: block of compressed and encrypted data containing the name=value session variable pairs
  4. KL1_CLISES_HMAC: HMAC-sha1 calculated based on the concatenation of the following values: SID, atime, and encrypted data block

Upon each request, the HMAC is calculated based on the content of the 3 Cookies supplied by the client and it is compared with KL1_CLISES_HMAC. The session is authenticated if the values are equal. Verification of session expiry follows, and if it is still valid, the session variables are decrypted and loaded.

The saving process is the inverse operation. The session data is compressed and encrypted, the current atime is saved and the HMAC is calculated using the SID, atime and KL1_CLISES_DATA. Hence, the data is registered via the above-mentioned Cookies.

Note that the AES (Advanced_Encryption_Standard) and HMAC keys are randomly generated at each startup to increase system security.

An example of Cookie content follows for a client-side session: 

   KL1_CLISES_DATA=333ec672947230fe40446b247d58ba5f
   KL1_CLISES_HMAC=8b5bcd9a8bfb1a4ac348b8bcf7f6a61bbe35a777
   KL1_CLISES_ATIME=1139916030
   klone_sid=5d09d95de64ef6cda04b05eed348ed82
  • Advantages:
  1. No RAM or disk space utilisation on the server.
  2. The session data access semantics are identical to those for server-side sessions; web applications can make use of client-side sessions transparently, by simply changing a configuration parameter.
  • Disadvantages:
  1. increased CPU consumption due to encryption and HMAC calculation (hardware chips can be used to free the CPU from such task).
  2. despite being usually negligible due the exiguous size of the sessions, one may need to take into account the increase in bandwidth necessary for the two-way transfer of session data for each HTTP request.

The two disadvantages are negligible if weighed against the usefulness and ease of use of client-side sessions in environments which for any reason don't allow for the server-side sessions option.

Retrieved from "https://en.wikipedia.org/w/index.php?title=HTTP_sessions:_Client_vs_Server_side&oldid=77242156"