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.
IMPLEMENTATION AND 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.
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.
COMPATIBILITY WITH WEB CACHES
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.