WO2003028275A2

WO2003028275A2 - Method for improving the performance of the secure socket layer protocol

Info

Publication number: WO2003028275A2
Application number: PCT/US2002/030800
Authority: WO
Inventors: Leslie Mccutcheon
Original assignee: Caw Networks, Inc.
Priority date: 2001-09-27
Filing date: 2002-09-27
Publication date: 2003-04-03
Also published as: WO2003028275A9; AU2002335783A1; WO2003028275A3

Abstract

A secure socket layer connection may be re-established between a client and a server over a public computer network without the need to recalculate a pre-master secret. After a request and an acknowledgment to connect between the client and server has been obtained, the client accesses a hash table to determine whether a prior connection has been made with the server. If so, the client obtains the prior pre-master secret contained in hash table in association with an identification for the server. The pre-master secret is then sent to the server such that each of the client and the server can then calculate the master key.

Description

Secure Socket Layer Connection Method and Apparatus

Background of the Invention

Field of the Invention

The present invention relates generally to secure socket layer (SSL) connections and, more particularly, to a novel SSL connection method and apparatus wherein a session maybe re-established between a client and a server using connection parameters calculated during the initial session.

Description of the Related Art

In a public computer network, such as the Internet, a connection is made between a client and a server using established protocols such that an exchange of data may occur between the client and the server. This data traverses the network in packets which are continually directed and redirected by network routers along varying paths in the network. At any point within the network, the packets may be read by any third party, irrespective of the authorization of such third party to read the packets. Accordingly, the normal exchange of data occurring between the client and the server is relatively insecure and, therefore, not conducive to electronic commerce in which the exchanged data between the client and the server is required to remain private, authenticated and secure.

To promote electronic commerce on the public network, the secure socket layer (SSL) connection protocol has been developed in which the packets traversing the public computer network are encrypted using commonly known public-private key encryption algorithms. Generally, the server makes available the public key to all clients and each client encrypts its transmitted packets using the public key with the server specified encryption algorithm. Although the encrypted packets may be read by an unauthorized third party, the private key known only to the server must be used to decrypt the packets. By providing a sufficient bit length to each of the public and private keys, decryption of the packets is relatively unlikely by the unauthorized third party due to the length of processing time even a relatively robust decryption algorithm would require.

To establish an SSL connection, the client transmits to the server a request for connection and the server responds and transmits to the client an acknowledgment. The request includes a predetermined number of randomly generated bytes commonly referred to as the client random. Similarly, the acknowledgment includes a predetermined number of randomly generated bytes commonly referred to as the server random.

After the exchange of the client and the server random, the client computes a pre-master secret. The pre-master secret is encrypted using the server public key and transmitted to the server and also temporarily maintained locally. Each of the client and the server then generate a master key from the client random, the server random and the pre-master secret, each also using the same algorithm. The client and the server then exchange each of their master keys, and if the master keys match a SSL session is initiated.

Each time the client wants to establish a SSL session with the server, the above process must be repeated. However, a limitation of the above process is that it is computationally intensive and disadvantageous^ results in a significantly slower rate of establishment of the connection as compared to an unsecured connection. Accordingly, this limitation and disadvantage may give rise to a disincentive by users of the public computer network to engage in electronic commerce. Furthermore, should a single secure transaction require several SSL sessions with the server, the user at the client may experience an unacceptable delay and refuse to engage in such transaction.

To overcome this disadvantage and limitation, the server may assign a session

ID to the initial session, and send this session ID to the client. After termination of the session, the client may re-establish and resume the session with the server by returning to the server the session ID. Although session resumption results in subsequent secure connections being established relatively quickly, a limitation is that an unauthorized third party could read the session ID and establish its own secure connection with server thereby disadvantageously affecting the user's security that the client. The security risk posed by this limitation and disadvantage may also act as a disincentive to users to engage in electronic commerce over a public computer network. This security risk may be mitigated, but not eliminated, by allowing the session ID to only be used for selected number of subsequent sessions or for a selected time duration after the initial session.

Accordingly, there exists a need in a public computer network to overcome one or more disadvantages and limitations of the prior art hereinabove set forth.

There also exist a need in a public computer network to provide for relatively quicker establishment of SSL connections with only minimal or none adverse effect to user security.

Summary of the Invention

An object of the present invention is to overcome one or more of the disadvantages and limitations of the prior art hereinabove set forth. It is a further objected the present invention to provide for relatively quicker establishment of SSL connections with only minimal or none adverse effect to user security in a public computer network.

According to the present invention, a secure socket layer connection method includes initiating a connection between a client and a server over a public computer network, determining whether a prior connection had been established between the client and the server for which a prior pre-master secret has been stored at the client, obtaining the prior pre-master secret, sending the prior pre-master secret to the server, and calculating at each of the client and the server a master key from the prior pre-master secret, whereby a connection between said client and said server may be established.

A feature of the present invention is that the pre-master secret is only calculated upon the first establishment of the connection with the server. Upon the second or other subsequent connection, the pre-master secret is reused. An advantage of reuse of the pre-master secret is that computational overhead at the client is eliminated upon establishment of the subsequent connections. A further advantage of the present invention over the session ID of the prior art is that the master key, being a function of the pre-master secret, the client random and the server random, is still unique for each subsequent connection.

These and other objects, advantages and features of the present invention will become readily apparent to those skilled in the art from a study of the following Description of the Exemplary Preferred Embodiments when read in conjunction with the attached Drawing and the appended Claims. Brief Description of the Drawings

Fig. 1 is a schematic block diagram of a computer network;

Fig. 2 is a flowchart useful to describe a secure socket layer connection method in the apparatus of Fig. 1; Fig. 3 is a flowchart of the initiating step of Fig. 2;

Fig. 4 is a flowchart useful to describe an additional embodiment to the method of Fig. 2;

Fig. 5 is a flowchart of one embodiment of the determining step of Fig. 2;

Fig. 6 is a flowchart of one embodiment of the obtaining step of Fig. 2; and Fig. 's 7A-D illustrate exemplary conditions to be satisfied prior to the obtaining step of Fig. 2.

Description of the Exemplary Preferred Embodiments

Referring now to Fig. 1, there is shown a public computer network 10, a plurality of clients 12, and a plurality of servers 14. Each of the clients 12 as a memory 16, which may be volatile or nonvolatile. The present invention is directed to apparatus and methods for providing a secure socket layer connection between at least one of the clients 12 and one of the servers 14. The apparatus of the present invention may be a computer readable medium that contains program code, which when read and executed performs the procedures set forth in the methods described below. Another apparatus of the present invention may be the above described components of the computer network in which the procedures described below are performed. Referring now to Fig. 2, there is shown a flow chart 18 useful to describe a secure socket layer connection method of the present invention. The method of the present invention includes initiating a connection between one client 12 and one server 14 over the public computer network 10, as indicated at step 20, and determining whether a prior connection had been established between the client 12 and the server 14 for which a prior pre-master secret is in memory 16 of the client 12, as indicated at step 22.

If the result of the determining step 22 is positive, the YES path is taken to obtaining the prior pre-master secret from the memory 16 of the client 12, as indicated at step 24, sending the prior pre-master secret to the server 14, as indicated at step 26, and calculating at each of the client 12 and the server 14 a master key from the prior pre-master secret, as indicated at step 28. Once the master key has been calculated, a connection between the client 12 and the server 14 may be subsequently established, as indicated at step 30, in accordance with conventionally known steps. For example, included at step 30 (Fig. 2) is the exchange of keys between the client 12 and the server 14 to determine that the master key is identical in each of the client 12 and the server 14 to indicate that the connection may be established.

If the result of the determining step 22 is negative, the above described connection method need not be terminated, and the step 26 of sending the pre-master secret to the server 14 may still be reached. Accordingly, in another embodiment of the present invention, should the result at step 22 be negative, the NO path is taken from step 22 to calculating a new pre-master secret, as indicated at step 32.

Referring now to Fig. 3, there is shown a detail of the step 20 of initiating the connection between the client 12 and the server 14. Initially, the client 12 sends a request for connection to the server 14, as indicated at step 34. The request for connection may also include the client 12 sending a client random to the server 14 as indicated at step to 36. As well known, the client random is a randomly generated alphanumeric value of a predetermined number of bytes which is generated each time the client 12 sends any request for connection.

Upon the server 14 receiving the request for connection from the client 12, the server 14 sends an acknowledgment back to the requesting client 12, as indicated at step 38. The acknowledgment may also include the server 14 sending a server random to the client 12, as indicated at step 40. Similarly as described above, the server random is a randomly generated alphanumeric value of a predetermined number of bytes which is generated each time the server 14 sends any acknowledgment .

The master key may be further calculated, as is well known in the art, as a function of the client random and the server random, in addition to the pre-master secret as indicated at step 28 (Fig. 2). The master key, as described hereinabove, is calculated at each of the client 12 and the server 14.

Furthermore, the acknowledgment may also include other server information sent to the client 12, as indicated at step 42. The other server information may include any of a static IP address of the server 14, a fully qualified string name of the server 14 or a server ID. In any event, the other server information may be used by the deteπriining step 22 to determine if there has been a prior connection between the client 12 and the server 14.

The other server information may also include a server certificate and server public key. The step 26 (Fig. 1) of sending the pre-master secret may also include encrypting the pre-master secret using a server specified encryption algorithm and the server public key prior to sending of the pre-master secret to the server 14.

Referring now to Fig. 4, in a further embodiment of the present invention, after a new pre-master secret is calculated at the client 12, as indicated at step 32, the new pre-master secret may then be stored in the memory 16 of the client 12, as indicated at step 44. The pre-master secret may be stored in any conventional manner, such as in a file or database. Generally, the storage of the pre-master secret is in accordance with a map or any other type of association wherein an element contains a key which is mapped or associated with a value.

In a preferred embodiment of the present invention, a hash table is used to store the new pre-master secret. As described above, upon receiving an acknowledgment from the server 14, other server information, indicated at step 42 (Fig. 3), includes information which uniquely identifies the server 14. This unique information may then be placed in hash table. For example, the static IP address of the server 14 may preferably be used. The new pre-master secret, calculated at step 32, may now, at step 44, be stored in the hash table in association with the static IP address of the server 14 to which connection is being made.

With reference to Fig. 5, there is shown a detail of the determining step 22 (Fig. 2) in accordance with another embodiment of the present invention. To determine that the acknowledgment sent by the server 14 to the requesting client 12 is coming from a server which the requesting client 12 has previously established a connection with, the client 12 may look up the information which uniquely identifies the server 14 in the hash table, as indicated at step 46. If an entry for the acknowledging server 14 is found in the hash table, as indicated at step 48, the YES path is taken to the obtaining step 24 (Fig. 2). Otherwise, if the entry is not found, the NO path is taken to the new pre-master secret calculating step 32 (Fig. 2).

Similarly, with reference to Fig. 6, there is shown a detail of the obtaining step 24 (Fig. 2) in accordance with yet another embodiment of the present invention. As indicated at step 50, the pre-master secret, stored in association with the information which uniquely identifies the server 14, is looked up in the hash table. If such stored pre-master secret is found, as indicated at step 52, the YES path is taken to the sending step 26 (Fig. 2). Otherwise, a new pre-master secret needs to be calculated, and the NO path is taken the new pre-master secret calculating step 32 (Fig. 2).

The stored pre-master secret may not be found, as described immediately above, if, for example, the entry in the hash table has expired. For example, once the calculated pre-master secret is stored in the hash table, a timer may be associated with such entry such that upon the expiration of the timer, the entry is no longer valid. The use of such a timer enhances security by mitigating the possibility of unauthorized third parties obtaining the stored pre-master secret and using it indefinitely.

Accordingly, with reference returning to Fig. 4, in a further embodiment of the present invention, a determination is made whether such time or has expired, as indicated at step 54. If the result is positive, the YES path is taken such that the entry for the pre-master secret is automatically deleted, as indicated at step 56. Upon a subsequent obtaining of the stored pre-master secret, the result at step 52 (Fig. 6) will be negative and the NO path from step 52 would be taken as described above. Alternatively, in another embodiment of the present invention, the entry of this pre-master secret need not be automatically deleted, as indicated it step 56, but may remain in the hash table subsequent to the expiration of the timer. In this embodiment, the. step 54 would be performed intermediate the step 50 and step 52 of Fig. 6. Accordingly, after the entry for the pre-master secret is looked up in the hash table at step 52, the determination of step 54 is made to determine whether the timer has expired for the entry. If so, the YES path is taken from step 54 two-step 56 to indicate that this entry is now to be deleted. Therefore, when step 52 is reached, the results will be negative and the NO path will be taken from step 52 as described above.

To further ensure security between the client 12 and the server 14, the stored pre-master secret may also be locally encrypted. With reference again to Fig. 4, subsequent to calculating the new pre-master secret, as indicated at step 32, the new pre-master secret is encrypted, as indicated at step 54. Subsequent to being encrypted, the new pre-master secret may then be stored, as described above in reference to step 44. If the pre-master secret is so encrypted, then upon the obtaining step 24 (Fig. 2) been performed, the encrypted pre-master secret must first be decrypted, as indicated at step 56.

Referring now to Fig. 7 A, in still another embodiment of the present invention, prior to the stored pre-master secret being obtained, as indicated at step 24 (Fig. 2), a determination may be made whether certain conditions have been satisfied, as best seen in step 58. If all of these conditions have been met, the YES path is taken to the obtaining step 24. Otherwise, the NO path is taken to the new pre-master secret calculating step 32 (Fig. 2). Any conditions may be specified. Typically, these conditions may be used to enhance security by preventing unauthorized connections to the server 14. For example, with reference to Fig. 7B, one exemplary condition may determine whether the number of connections to particular server 14 has been exceeded, as indicated at step 60. If the result of this determination is negative, the NO path may then be taken to a determination of any other condition or to the obtaining step 24. Otherwise, the YES path is taken to the new pre-master secret calculating step 32.

With reference to Fig. 7C, another exemplary condition may determine whether an elapsed time from an initial, or other previous, connection with the server 14 has expired, as indicated at step 62. If the result of this determination is negative, the NO path may then be taken to a determination of any other condition or to the obtaining step 24. Otherwise, the YES path is taken to the new pre-master secret calculating step 32.

With reference to Fig. 7D, yet another exemplary condition may determine whether the server 14 to which connection is being attempted always requires a new pre-master secret to be calculated. If the result of this determination is negative, the NO path may then be taken to a determination of any other condition or to the obtaining step 24. Otherwise, the YES path is taken to the new pre-master secret calculating step 32.

The has been described above novel apparatus and methods for a secure socket layer connection between a client and server over a public computer network. Those skilled in the art may now make numerous uses of, and departures from, the above described exemplary embodiments without departing from the inventive principles disclosed herein. Accordingly, the present invention is to be defined solely by, and accorded the full scope, of the appended Claims.

Claims

The ClaimsWhat is claimed as the invention is:

1. A secure socket layer connection method comprising: initiating a connection between a client and a server over a public computer network; determining whether a prior connection had been established between said client and said server for which a prior pre-master secret has been stored at said client; obtaining said prior pre-master secret; sending said prior pre-master secret to said server; and calculating at each of said client and said server a master key from said prior pre-master secret, whereby a connection between said client and said server may be established.

2. A method as set forth in Claim 1 further comprising: calculating at said client a new pre-master secret in the event said prior pre- master secret is not stored, said sending step sending said new pre-master secret to said server and said calculating step calculating said master key from said new pre- master secret.

3. A method as set forth in Claim 1 wherein said initiating step includes: sending a request for connection from, said client to said server; and sending an acknowledgment of said request from said server to said client, said acknowledgment uniquely identifying said server.

4. A method as set forth in Claim 3 wherein said sending said acknowledgment step includes sending a static IP address of said server.

5. A method as set forth in Claim 3 wherein said sending said acknowledgment step includes sending of fully qualified string name of said server.

6. A method as set forth in Claim 3 wherein said sending said acknowledgment step includes sending a server ID.

7. A method as set forth in Claim 3 wherein said sending said request step includes: sending a client random to said server, said calculating step further calculating said master key from said client random.

8. A method as set forth in Claim 3 wherein said sending said acknowledgment step includes: sending a server random to said client, said calculating step further calculating said master key from said server random.

9. A method as set forth in Claim 2 further comprising: storing at said client said new pre-master secret, said new pre-master secret becoming said prior pre-master secret upon being stored.

10. A method as set forth in Claim 9 further comprising: encrypting said new pre-master secret prior to said storing step; and decrypting said prior pre-master secret prior to said sending step.

11. A method as set forth in Claim 9 further comprising: removing said pre-master secret from said client upon the expiration of a predetermined time limit.

11. A method as set forth in Claim 2 said sending step includes: encrypting as a function of a server public key said pre-master secret prior to said sending step.

12. A method as set forth in Claim 1 further comprising: satisfying predetermined conditions prior to said sending step.

13. A method as set forth in Claim 12 wherein said satisfying step includes determining that a selected number of connections between said client and said server has not been exceeded.

14. A method as set forth in Claim 12 wherein said satisfying step includes determining that an elapsed time from said prior connection has not been exceeded.

15. A method as set forth in Claim 12 wherein said satisfying step includes determining that a pre-master secret must not be computed for each connection to said server.

16. A method as set forth in Claim 1 wherein said obtaining step includes: accessing a hash table adapted to contain at least an ID for said server and said prior pre-master secret associated with said ID; and determining whether said ID and said associated prior pre-master secret exist in said hash table.

17. A method as set forth in Claim 16 further comprising: calculating a new pre-master secret to be associated with said server in the event said hash table does not contain said associated prior pre-master secret.