Secure Web Server Performance Dramatically Improved by CachingSSL Session Keys
Arthur Goldberg, Robert Buff, Andrew Schmitt
[artg, buff, schm7136]@cs.nyu.edu
Computer Science Department Courant Institute of Mathematical Science New York University715 Broadway, Room 711 New York, New York 10003
Performance measurements of secure production Web servers show that reusing cachedSSL session keys can significantly reduce clientresponse time. The time to download secure Webdocuments is reduced between 15% and 50% for 5geographically diverse U.S. sites.
The importance of electronic commerce iswidely acknowledged. Surveys of Web usersindicate that poor performance is a major cause of dissatisfaction. We have embarked on a major study of the performance of secure Webcommunications. Here we present results provingthe importance of session key caching for improving end-to-end performance.While the computational cost of publickey encryption is widely understood [Kaufman95],and has led to the development of session keycaching
across short-lived transactions as in theWeb, there have been no detailed studies of the performance of key exchange in the Web.We briefly review the operation of secureWeb communications. Conducting securecommunications typically involves the followingsteps:
This work has been supported by an IBMPartnership Award.
Published in the “Workshop on Internet Server Performance”, held in conjunction withSIGMETRICS’98, June 23, 1998.
Session key caching is also known as ‘sessionresume’ or ‘session restart’.
A client establishes a TCP session with aserver, which involves one round-trip messageexchange.
On top of TCP, the client and server establisha secure SSL communication channel[Freier96]. The client and server exchangesecret session keys that will be used to encryptand decrypt application messages.
On top of SSL, the client and server exchangeone or more HTTP messages. (Multiplemessages would be exchanged over keep-aliveor persistent connections [Fielding98].)When establishing an SSL channel theclient and server may either create new sessionkeys or reuse cached keys. Establishing an SSLchannel first attempts to reuse a cached sessionkey. Exchanging a cached session key takes oneround-trip. If this fails, a new session key is createdand encrypted with a public key for transmission.This takes two round trips. ([Bolyard97] nicelytraces SSL session setup.)We have measured the time to establishSSL connections for multiple Web sites at manytimes of the day over a period of several weeks.We find that 1) reusing a cached a session keysignificantly decreases the time to establish an SSLsession, and that 2) in some situations the time toestablish an SSL session is only slightly greater than the time to establish a TCP session when acached session key is reused.
We call our measurement apparatusWebPerf. WebPerf consists of a Web robot and a back-end database. The robot is written in C++ andcompiled with Visual C++ version 5.0, with