People's Newsroom


Since the Web is a complex distributed system, where multiple simultaneous requests are fired by the browser, request flows often differ from the flows drawn on paper. One example of modified flow requests that arrive at the server in a different order than they were sent. A second example is middleboxes changing the request flow, such as a Web cache responding to a request, which will thus not be sent to the server. Since these scenarios are common on the Web, it is important that they are robustly handled by a newly introduced session management mechanism.

The design of SecSess explicitly takes modified request flows into account, and effectively achieves full compatibility with currently deployed Web caches, both within the browser and on the intermediate network. First, by only adding integrity protection, the caching of content is effectively enabled. Second, SecSess is robust enough to deal with out-of-order requests and cached responses, which is fairly trivial once a session is established, but challenging during establishment. If the client’s public component (request 2) would get lost in transit, for example when an intermediate cache responds to a request, the server would not be able to complete the session establishment, effectively breaking the protocol. Concretely, SecSess addresses this by continuing to send the public component as long as the server has not confirmed the session establishment (response 2), effectively preventing it from getting lost in a modified request flow. We discuss the concrete impact of this decision during the performance evaluation.


To show the feasibility of SecSess on the Web, as well as to support evaluation, we created a proof-of-concept implementation. At the client-side, we have extended the Firefox browser with support for SecSess, heavily leveraging the support of OpenSSL’s crypto library. At the server-side, we have implemented a session management middleware module for the Express framework, which runs on top of Node.js, an event-driven bare metal Web server. The middleware amounts to a mere 113 meaningful lines of code, and a binary module linking the OpenSSL library is 178 meaningful lines of code. The prototype implementation of SecSess enables a thorough evaluation, both on performance and on compatibility with the current Web, as covered in the remainder of this section. The next section discusses both client and server-side strategies for evolving the prototype into a practically deployable solution.


The security evaluation of SecSess with regard to the proposed in-scope threat model considers several concrete attack vectors. The first is the capability to run attacker-controlled scripts within the context of the target application. A session hijacking or session fixation attack using this attack vector will no longer succeed, since none of SecSess’s data is available to the JavaScript environment. Additionally, the Session request and response headers contain only public information, of no use to an attacker. Session transfer attacks can also be performed on the network level. Eavesdropping attacks on the session management mechanism are effectively mitigated by SecSess, since the shared secret used for calculation of the HMACs is never communicated over the wire, and the Hughes variant of the key exchange can withstand passive attacks. Next to passive attacks, an attacker can also try to modify existing requests, or re-attach a valid HMAC to a crafted request. Such attempts will fail as well, because the HMAC is based on the contents of the request, effectively preventing any modifications to go unnoticed.

Performance Overhead. To get correct measurements, we calculated 100 data points for each step, which contain the average computation time of 100 runs each, executed from within JavaScript code, both on the client-side (browser add-on) as the server-side (Node.js).  The most notable results are the very limited overhead at the client-side, especially after the session has been established (from request 3 onwards). At the server-side, there is a significant pre-calculation overhead (212ms) for generating the required parameters. This overhead is induced by the Hughes variant of the key exchange, which requires the inverse of the server’s private component. Note that these parameters are session-independent, and can be pre-calculated offline in bulk, and read from a file on a per-need basis. After the parameters have been calculated, the additional overhead for actually establishing and maintaining a session is negligible.

Network Overhead. In a Web context, network overhead can be caused by increased message sizes, but also by introducing additional requests or round trips in the flow of requests. By design, SecSess follows the same sequence of requests and responses used in currently existing applications, which deploy cookie-based session management mechanisms, so no additional requests or round trips are required. However, based on the average header sizes in the cookie-based session management mechanisms of the Alexa top 5,000 sites, SecSess leads to 25.58% reduction in the size of the session management header of requests. On the contrary, SecSess leads to increased header sizes during the session establishment phase, which ends after the server has confirmed the session establishment (response 2). These header sizes increase due to the transmission of the public components of client and server. Concretely, the request headers during session establishment suffer an 867.44% increase and the response header a 9.19% increase.


Web caches are widely deployed throughout the Web, enabling faster page loads and limiting the required bandwidth. Caches are often deployed in a transparent way, where they intercept HTTP traffic and respond when they have the resource in cache. When a cache responds to a request, the request is never forwarded to the target server, resulting in a modified request flow. As stated in one of the proposed design objectives, newly proposed session management mechanisms should be able to cope with infrastructure components of the Web modifying request flows.

SecSess is robustly designed to be compatible with such modified request flows. We have confirmed this compatibility empirically by running experiments with two popular caches, Squid and Apache Traffic Server, configured as a forwarding proxy. In our setup, we add SecSess session management on top of the requests sent between the browser and the Web servers of the Alexa top 1,000 sites. Since these servers do not know about SecSess, we have added a dedicated SecSess-proxy in between, which will handle the SecSess session management with the browser (full arrows), while forwarding the request to the actual Web server (dashed arrows). Finally, we add the cache in between the browser and the SecSess-proxy. This setup allows us to test the establishment and maintaining of a session with traffic patterns from the Alexa top 1,000 sites. Additionally, when the cache responds to a request, the SecSess-proxy will never see the request. This effectively allows us to verify the robustness of SecSess when dealing with modified request flows.

To maximize the potential of the cache, we visited each site in the Alexa top 1,000 twice. For the Squid run, 52,947 requests were sent to 5,167 distinct hosts. Of these requests, 5,008 were cached, of which 830 were during session establishment, and 4,178 were when an established session was already present. For the Apache Traffic Server run, we observed 44,173 requests to 4,660 hosts in total, of which 4,263 were served from the cache. 1,169 cached responses occurred during session establishment, and 3,094 with an established session. During these requests, SecSess robustly handled session management, without losing an established session, or failing to establish a session.

Back to top button