U.S. patent application number 12/327693 was filed with the patent office on 2009-03-26 for reducing latency of split-terminated secure communication protocol sessions.
This patent application is currently assigned to RIVERBED TECHNOLOGY, INC.. Invention is credited to Case Thomas Larsen, Naveen Maveli, Shashidhar Merugu.
Application Number | 20090083538 12/327693 |
Document ID | / |
Family ID | 40472979 |
Filed Date | 2009-03-26 |
United States Patent
Application |
20090083538 |
Kind Code |
A1 |
Merugu; Shashidhar ; et
al. |
March 26, 2009 |
REDUCING LATENCY OF SPLIT-TERMINATED SECURE COMMUNICATION PROTOCOL
SESSIONS
Abstract
A method is provided for establishing a split-terminated secure
communication connection between a client and a server. A first
network intermediary intercepts a secure communication connection
request directed from the client to the server. A second
intermediary having a digital certificate in the name of the server
(and a corresponding private key) acts in place of the server to
establish a first secure communication session with the client,
during which it receives a secret from the client for generating
the session key. The second intermediary supplies the secret and/or
the session key to the first intermediary, which allows the first
intermediary to establish follow-on secure communication sessions
in which the secret is reused. The second intermediary may also
supply the first intermediary with a copy of its certificate so
that it can respond to new secure communication requests and, yet
further, may also supply a copy of the private key.
Inventors: |
Merugu; Shashidhar;
(Mountain View, CA) ; Larsen; Case Thomas; (Union
City, CA) ; Maveli; Naveen; (Sunnyvale, CA) |
Correspondence
Address: |
PARK, VAUGHAN & FLEMING LLP
2820 FIFTH STREET
DAVIS
CA
95618
US
|
Assignee: |
RIVERBED TECHNOLOGY, INC.
San Francisco
CA
|
Family ID: |
40472979 |
Appl. No.: |
12/327693 |
Filed: |
December 3, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11489414 |
Jul 18, 2006 |
|
|
|
12327693 |
|
|
|
|
60992071 |
Dec 3, 2007 |
|
|
|
60707804 |
Aug 10, 2005 |
|
|
|
Current U.S.
Class: |
713/153 |
Current CPC
Class: |
H04L 9/0827 20130101;
H04L 9/3263 20130101; H04L 2209/76 20130101; H04L 9/3271 20130101;
H04L 2209/56 20130101; H04L 63/0428 20130101; H04L 63/0281
20130101; H04L 63/0823 20130101 |
Class at
Publication: |
713/153 |
International
Class: |
H04L 9/00 20060101
H04L009/00 |
Claims
1. A method of establishing a split-terminated secure communication
connection between a client computing device and a server computing
device, the method comprising: intercepting a request for a secure
communication connection from the client, at a first intermediary
in a pair of intermediaries situated in a path of communication
from the client to the server; establishing a secure communication
session between the client and a second intermediary in the pair of
intermediaries; and migrating a master secret used to generate a
key associated with the secure communication session to the first
intermediary; wherein the master secret was derived from a client
secret received at the second intermediary during establishment of
the secure communication session.
2. The method of claim 1, wherein said migrating the master secret
comprises transmitting the client secret and the key from the
second intermediary to the first intermediary.
3. The method of claim 1, further comprising: at the first
intermediary: receiving a secure data request from the client;
decrypting the secure data request with a first key associated with
the secure communication session; encrypting the data request with
a second key associated with a second secure communication session
established between the first intermediary and the second
intermediary; and forwarding the data request to the second
intermediary; and at the second intermediary: decrypting the data
request with the second key; and submitting the data request to the
server.
4. The method of claim 3, wherein said submitting the data request
to the server comprises: encrypting the data request with a third
key associated with a third secure communication session
established between the second intermediary and the server.
5. The method of claim 1, wherein: the client and the first
intermediary are coupled by a first local communication link; the
server and the second intermediary are coupled by a second local
communication link; and the first intermediary and the second
intermediary are coupled by a wide area network.
6. The method of claim 1, further comprising, after termination of
the secure communication session: intercepting a reuse connection
request from the client at the first intermediary, wherein the
reuse connection request attempts to reuse the master secret; and
establishing a second secure communication session between the
client and the first intermediary.
7. The method of claim 1, wherein the second secure communication
session is established without participation by the second
intermediary or the server.
8. A computer-readable medium storing instructions that, when
executed by a computer, cause the computer to perform a method of
establishing a split-terminated secure communication connection
between a client computing device and a server computing device,
the method comprising: intercepting a request for a secure
communication connection from the client, at a first intermediary
in a pair of intermediaries situated in a path of communication
from the client to the server; establishing a secure communication
session between the client and a second intermediary in the pair of
intermediaries; and migrating a master secret used to generate a
key associated with the secure communication session to the first
intermediary; wherein the master secret was derived from a client
secret received at the second intermediary during establishment of
the secure communication session.
9. A method of establishing a secure communication channel between
a client computing device and a server computing device, the method
comprising: at a first intermediary interposed in a communication
path between the client and the server, intercepting a request for
a secure communication connection directed to the server; during a
secure protocol handshaking process with the client, accepting a
client-key-exchange message comprising a client secret for
generating a key; forwarding the client-key-exchange message to a
second intermediary; receiving from the second intermediary a
master secret derived from the client secret; and establishing a
secure communication session with the client.
10. The method of claim 9, wherein said accepting, forwarding,
receiving and establishing are performed by the first
intermediary.
11. The method of claim 9, further comprising, prior to said
intercepting: receiving at the first intermediary from the second
intermediary, a digital certificate in a name of the server.
12. The method of claim 9, further comprising, after termination of
the secure communication session: at the first intermediary,
intercepting a reuse connection request directed to the server from
the client, wherein the reuse connection request attempts to reuse
the master secret; and establishing a second secure communication
session between the client and the first intermediary.
13. A computer-readable medium storing instructions that, when
executed by a computer, cause the computer to perform a method of
establishing a secure communication channel between a client
computing device and a server computing device, the method
comprising: at a first intermediary interposed in a communication
path between the client and the server, intercepting a request for
a secure communication connection directed to the server; during a
secure protocol handshaking process with the client, accepting a
client-key-exchange message comprising a client secret for
generating a key; forwarding the client-key-exchange message to a
second intermediary; receiving from the second intermediary a
master secret derived from the client secret; and establishing a
secure communication session with the client.
14. A method of establishing a secure communication channel between
a client computing device and a server computing device, the method
comprising: at a first intermediary interposed in a communication
path between the client and the server: receiving from a second
intermediary a digital certificate issued in a name of the server
and a private key associated with the certificate; and intercepting
a request for a secure communication connection directed to the
server; accepting a client-key-exchange message comprising a client
secret for generating a symmetric key; decrypting the
client-key-exchange message with the private key; and establishing
a secure communication session between the client and the first
intermediary.
15. The method of claim 14, further comprising: notifying the
second intermediary of the request for a secure communication
connection.
16. A network configured to optimize secure communications between
a client and server, the network comprising: a server-side
intermediary located in a communication path between the client and
the server, wherein the server-side intermediary comprises: a
digital certificate associated with a name of the server, wherein
the certificate enables the server-side intermediary to proxy for
the server and establish a first secure communication session with
the client in response to a client request directed to the server;
a first secret received from the client during establishment of the
first secure communication session; and a first master secret
derived from the first secret; and a client-side intermediary
installed in the communication path and coupled to the server-side
intermediary by a wide area network, wherein the client-side
intermediary comprises: the first master secret; and a key
associated with the first secure communication session; wherein the
first master secret are received at the client-side intermediary
from the server-side intermediary.
17. The apparatus of claim 16, wherein said client-side
intermediary is configured to: intercept a reuse connection request
from the client to establish a new secure communication connection
after the first secure communication session terminates, wherein
the reuse request specifies that the first master secret is to be
reused; and proxy for the server to establish a second secure
communication session with the client in response to the reuse
request.
18. The apparatus of claim 16, wherein said client-side
intermediary further comprises: the certificate; wherein the
certificate enables the client-side intermediary to proxy for the
server and respond to a second request for a secure communication
connection intercepted from the client.
19. The apparatus of claim 18, wherein said client-side
intermediary is further configured to: forward to the server-side
intermediary, for decryption with a private key corresponding to
the certificate, a client-key-exchange message received from the
client; and receive from the server-side intermediary a second
master secret derived from a second secret extracted from the
client-key-exchange message.
20. A network configured to optimize secure communications between
a client and server, the network comprising: a server-side
intermediary located in a communication path between the client and
the server, wherein the server-side intermediary comprises a
digital certificate associated with a name of the server; and a
private key corresponding to the digital certificate; and a
client-side intermediary installed in the communication path and
coupled to the server-side intermediary by a wide area network,
wherein the client-side intermediary comprises: the digital
certificate; and the private key corresponding to the
certificate.
21. The apparatus of claim 20, wherein said client-side
intermediary is further configured to: decrypt a
client-key-exchange message received from the client; and derive a
master secret from a secret extracted from the client-key-exchange
message.
22. The apparatus of claim 20, wherein said client-side
intermediary receives the digital certificate and the private key
from the server-side intermediary.
Description
RELATED APPLICATIONS
[0001] The present application claims priority to U.S. Provisional
Patent Application No. 60/992,071, which was filed Dec. 3, 2007, is
entitled "Reducing Latency of Split-Terminated Secure Communication
Protocol Sessions," and which is incorporated herein by reference.
In addition, the present application is a continuation-in-part of
U.S. patent application Ser. No. 11/489,414, which was filed Jul.
18, 2006 and is also incorporated herein by reference, and which
claims priority to U.S. Provisional Patent Application No.
60/707,804, filed Aug. 10, 2005.
FIELD
[0002] The present invention relates to network optimization in
general, and in particular to accelerating network transactions
including data conveyed using secure communications protocols.
BACKGROUND
[0003] Protocols that use either or both public-key cryptographic
techniques and symmetric-key cryptographic techniques are often
used to establish secure communications across an untrusted network
or other communication link. Typically, public-key cryptography has
better security properties but is more expensive computationally
than symmetric-key cryptography. Thus, the two types of
cryptography may be combined to use public-key techniques to
negotiate a symmetric cipher between two entities. The
symmetric-key cipher may then be used for bulk data transfer
between the entities. Secure Socket Layer (SSL) and Transport Layer
Security (TLS) are widely-used examples of secure communication
protocols that have this form, as well as IPSec (Internet Protocol
Security) when security associations are negotiated using RSA-based
(Rivest, Shamir & Adleman) mechanisms for IKE (Internet (or
IPsec) Key Exchange).
[0004] Secure communication protocols often add a computational
cost to each secured connection. For server computers providing
many simultaneous secure connections to client computers, the
additional computational overhead imposed by secure communication
protocols can be significant. To decrease the computational
overhead of secure communication protocols for computers providing
large numbers of secure connections, there are various devices that
specialize in terminating secure connections. These secure
connection termination devices manage the cryptographic and other
security related aspects of the connection, thereby relieving
server systems providing services to client systems of the
additional overhead imposed by the secure connection. In general,
these secure connection termination devices appear to client
systems as servers providing secure connections.
[0005] A secure connection termination device is configured in much
the same way as a server that supports secure communication
protocols, including, for example, private keys, public keys and
security certificates. From a security perspective, a secure
connection termination device is identical to a server and
therefore should be protected identically. If the security of a
secure connection termination device is compromised, for example by
the loss of a server's private key, attackers would be able to set
up a fake server that would be trusted by client systems that use
the secure communication protocol.
[0006] A transaction accelerator such as that described in U.S.
Pat. No. 7,120,666 (McCanne) can offer performance improvement for
operations across a wide-area network (WAN), but only when the data
being communicated is either intelligible (i.e., the transaction
accelerator can interpret at least parts of the protocol) or
repeating (i.e., identical data crosses the network in identical
format). The use of secure communication protocols such as SSL and
TLS thus typically frustrates transaction acceleration, because
cryptography (by design) renders encrypted data unintelligible and
non-repeating.
[0007] A method of securing end-to-end communications between a
client and a server separated by transaction accelerators is
described in U.S. Patent Publication No. US2007/0038853
(application Ser. No. 11/489,414), and involves the use of separate
split-terminated secure protocol sessions between a transaction
accelerator and the client and the server.
[0008] However, before a fully secured path can be established
between the client and the server, even using split-terminated
sessions, security protocols such as SSL or TLS require handshaking
negotiations that involve multiple round-trip communications.
Because some of these communications must traverse a WAN, the
combined latency of the round-trips can delay the satisfaction of a
data request from the client.
SUMMARY
[0009] In some embodiments of the invention, a split-terminated
secure communication connection is transparently established
between a client and a server to enable them to securely issue and
respond to client data requests, while also allowing intervening
network intermediaries to optimize the client-server
communications.
[0010] In these embodiments, a first intermediary intercepts a
request for a secure communication connection from the client and a
second intermediary establishes a secure communication session with
the client. The second intermediary possesses a digital certificate
enabling it to act as the server (and also possesses a
corresponding private key). A client secret used to generate the
secure communication session key, a master secret derived from the
client secret, and/or the session key itself, are supplied to the
first intermediary by the second intermediary.
[0011] The first and second intermediaries may also establish
between themselves a secure tunnel that traverses a wide area
network, or may have established such a link beforehand. The second
intermediary may further establish another secure communication
session with the server. Thus, data requests can then be securely
submitted from the client to first intermediary (protected by a
first session key), forwarded from the first intermediary to the
second intermediary (protected by a second key), and then delivered
to the server (protected by a third key). Responses to data
requests can similarly be delivered to the client in the opposite
direction.
[0012] In some embodiments of the invention, after this secure
communication connection terminates (or one or more of the
split-terminated sessions ends), the first intermediary intercepts
a reuse connection request from the client at the first
intermediary. The reuse connection request solicits the use of a
handshaking process in which the client secret is reused. Because
it already possesses this secret, the first intermediary can
establish a new secure communication session with the client
without involving the second intermediary or the server.
[0013] In some embodiments of the invention, the second
intermediary may also supply the first intermediary with a copy of
its digital certificate. In these embodiments the first
intermediary can respond to a new secure communication connection
request from the client, but will forward to the second
intermediary a client-key-exchange message (or similar message)
encrypted with the public key extracted from the certificate. The
second intermediary then returns to the first intermediary the
secret derived from the client-key-exchange message.
[0014] In some embodiments of the invention, the second
intermediary may also supply the first intermediary with the
private key corresponding to the certificate. The first
intermediary may then establish secure communication sessions with
the client without assistance from the second intermediary.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] FIG. 1 is a block diagram depicting an environment in which
secure communication protocol sessions may be split-terminated,
according to some embodiments of the invention.
[0016] FIG. 2 is a time sequence diagram demonstrating a full
handshaking process for establishing a split-terminated secure
communication session, according to some embodiments of the
invention.
[0017] FIG. 3 is a time sequence diagram demonstrating a reuse
handshaking process for establishing a split-terminated secure
communication session, according to some embodiments of the
invention.
[0018] FIG. 4 is a time sequence diagram demonstrating a full
handshaking process for establishing a split-terminated secure
communication session with reduced latency, according to some
embodiments of the invention.
[0019] FIG. 5 is a time sequence diagram demonstrating a full
handshaking process for establishing a split-terminated secure
communication session with further reduced latency, according to
some embodiments of the invention.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
[0020] The following description is presented to enable any person
skilled in the art to make and use the invention, and is provided
in the context of a particular application and its requirements.
Various modifications to the disclosed embodiments will be readily
apparent to those skilled in the art, and the general principles
defined herein may be applied to other embodiments and applications
without departing from the scope of the present invention. Thus,
the present invention is not intended to be limited to the
embodiments shown, but is to be accorded the widest scope
consistent with the principles and features disclosed herein.
[0021] In embodiments of the invention described herein, methods
are provided for reducing the latency with which split-terminated
secure communication sessions may be established. In these
embodiments, a client-server communication connection protected in
accordance with a secure communication protocol (e.g., SSL or
Secure Sockets Layer, TLS or Transport Layer Security) may be
split-terminated in order to enable optimization of the underlying
communications (e.g., via transaction acceleration).
[0022] Although the methods are described as they may be
implemented for SSL or TLS, similar methods for use with other
secure communication protocols may be derived from the following
discussion without exceeding the scope of the current
invention.
[0023] FIG. 1 illustrates an environment in which split-terminated
secure communication sessions may be established in some
embodiments of the invention.
[0024] In this environment, client 110 communicates with server 170
in a client-server relationship. Intermediaries 130, 150 are
situated in the path of communications between client 110 and
server 170.
[0025] Intermediaries 130, 150 are coupled to WAN (Wide Area
Network) 140, while client 110 is coupled to intermediary 130 via
LAN (Local Area Network) 120 and server 170 is coupled to
intermediary 150 via LAN 160. Thus, intermediary 130 is relatively
local to client 110, while intermediary is local to server 170
(e.g., within the same data center).
[0026] In the embodiment of FIG. 1, WAN 140 is characterized by
relatively high latency and low bandwidth in comparison to LANs
120, 160. In other embodiments of the invention, other types of
communication links may be employed. For example, LAN 120 and/or
LAN 160 may be WANs.
[0027] Intermediary 130 may be termed a "client side intermediary"
(or CSI) and intermediary 150 may be termed a "server side
intermediary" (or SSI) to reflect their relative positions within
environment 100. Although not shown in FIG. 1, additional client
side intermediaries may also cooperate with server side
intermediary 150, and/or client side intermediary 130 may cooperate
with other server side intermediaries.
[0028] In one particular embodiment of the invention,
intermediaries 130, 150 are Steelhead.TM. transaction accelerators
from Riverbed.RTM. Technology, and are configured to optimize
communications and applications (e.g., through compression or
acceleration). In other embodiments, the intermediaries may be
configured to perform other operations in addition to or instead of
optimization, such as routing, caching, etc.
[0029] All communication traffic between client 110 and server 170
may traverse intermediaries 130, 150 in the illustrated embodiment
of the invention. One or both intermediaries may also handle
traffic between client 110 and entities other than server 170,
and/or traffic between server 170 and other entities. In other
embodiments, the client and server may also employ other
communication paths that skip one or both of the
intermediaries.
[0030] Server 170 possesses a valid digital certificate that, among
other things, identifies the server and contains the server's
public key for use in a PKE (Public Key Encryption) scheme. Server
170 also possesses the corresponding private key. Client 110 has
received, verified and trusts a digital certificate of the
authority that signed the server's certificate.
[0031] Server side intermediary 150 possesses one or more digital
certificates issued by a certificate authority trusted by client
110 (e.g., the same authority that issued the server's
certificate). At least one of the certificates assigns intermediary
150 the same name that was assigned to server 170 in the server
certificate loaded by client 110.
[0032] It may be noted that no special application, utility or
plug-in need be installed on client 110 in order for it to benefit
from embodiments of the invention described herein.
[0033] U.S. patent application Ser. No. 11/489,414, entitled "Split
Termination for Secure Communication Protocols", describes a method
for establishing split-terminated communication sessions between
client 110 and server 170 that are secured using SSL, TLS or other
appropriate secure communication protocol. Described herein are
methods for reducing the latency with which split-terminated secure
communication sessions may be established.
[0034] In a split-terminated secure communication session, a secure
communication connection between two endpoints (e.g., client 110
and server 170) is replaced or simulated by multiple secure
communication sessions involving the two endpoints and one or more
intermediate entities (e.g., intermediaries 130, 150).
[0035] In addition, in the split-terminated sessions the
traditional roles of an endpoint in establishing and conducting
secure communications are split. For example, the role of
negotiating a connection with the other endpoint (client 110) may
be handled by one entity, such as intermediary 150. However, the
subsequent tasks of encrypting and decrypting communications with
the other endpoint are handled elsewhere--such as at intermediary
130.
[0036] The manner in which a secure channel between client 110 and
server 170 is established using split-terminated secure
communication sessions may vary, depending not only on the
communication protocol used to secure the sessions, but also on
which form of handshaking is performed.
[0037] For example, the SSL communication protocol provides a
"full" handshake process to be performed when a client opens a
first session with a particular server. As part of this process the
client provides a secret to be used to generate a symmetric
encryption key to encrypt and decrypt the client-server
communications. In some special circumstances, the server may also
provide a secret (e.g., via a server-key-exchange message).
[0038] However, the protocol also provides a "reuse" handshake
process that may be implemented when a client that established a
session with a server wishes to quickly establish another session.
If the client's secret has not expired, the reuse handshake process
allows the communicants to rely on their previous level of trust
and omit sharing another client secret.
[0039] In a traditional computing environment in which the client
and server are separated by a WAN such as the Internet, both the
full and reuse handshaking processes require multiple round-trip
communications between the client and server. Methods described
below for establishing split-terminated secure communication
sessions allow either or both the full and reuse handshaking
processes to be performed with fewer messages having to be
exchanged over the WAN, thereby reducing latency experienced by the
client.
[0040] FIG. 2 is a time sequence diagram demonstrating a full SSL
handshaking process for establishing a split-terminated secure
communication connection between a client and a server, according
to some embodiments of the invention.
[0041] In one such embodiment, client 210 communicates with client
side intermediary (CSI) 230 via a LAN, CSI 230 communicates with
server side intermediary (SSI) 250 via a WAN, and SSI 250
communicates with server 270 directly or via another LAN. The
directed vectors between these entities represent messages involved
in full handshaking process 200.
[0042] In this embodiment, at time sequence 282 the client
initiates a secure communication session. For purposes of clarity,
data exchanges between protocol layers up through the transport
protocol layer (e.g., TCP) are omitted so that the discussion can
be focused on the SSL handshaking process.
[0043] After time sequence 282, or possibly in advance of time
sequence 282, CSI 230 and SSI 250 establish a secure channel or
tunnel between them, so that communications exchanged across the
WAN are protected. In one implementation they employ SSL to
establish a symmetric key (with either intermediary acting as
client), although in other implementations they may employ a
different encryption scheme. A symmetric key used by the CSI and
SSI to encrypt/decrypt messages sent via the tunnel is represented
herein as Kt.
[0044] When the client initiates the secure session, it issues an
SSL Client-Hello (C-H) message toward the entity to which it wishes
to submit a data request--server 270. The Client-Hello message
comprises a client-based seed that will serve as one component in
the production of a master secret for use in generating a key for
the client's session. The absence of curly braces "{" and "}"
around the message indicates that the message is sent as clear
text. The Client-Hello message is subsequently encrypted by CSI 230
and forwarded to SSI 250. This message is represented in FIG. 2 as
"{C-H} Kt" to indicate that it is encrypted using the
intermediaries' key Kt.
[0045] SSI 250 decrypts the Client-Hello message (with Kt) but,
instead of forwarding the client's hello message to server 270, it
generates and issues its own Client-Hello message (C-H). This
initiates an SSL handshaking process between the SSI and the
server. In an alternative embodiment of the invention, instead of
generating a new Client-Hello message, the SSI simply forwards the
hello message it received from the CSI.
[0046] In response to whichever Client-Hello message the SSI
issues, the server sends a clear text message comprising
Server-Hello (S-H), a digital Certificate (C) belonging to the
server (which includes a public asymmetric key) and
Server-Hello-Done (SHD). The Server-Hello message comprises a
server-based seed that will be another component in the production
of a master secret.
[0047] SSI 250 responds with a message signaling Client Key
Exchange (CKE) (comprising a secret encrypted with the server's
public asymmetric key), Change-Cipher-Specification (CCS) (to
specify that the communicants are to start encrypting their
communications using a key derived from the master secret) and
Finished (F) (which includes an encrypted hash of the communicants'
handshaking messages). Server 270 completes the handshaking by
signaling CCS and F.
[0048] As a result of the handshaking between SSI 250 and server
270, at time sequence 284 both entities possess symmetric key Ks,
which will be used to encrypt communications between them. Note
that in a communication environment in which the link between the
SSI and the server is fully secured and trusted, they may
communicate in the clear and this handshaking process may be
omitted.
[0049] The server side intermediary now proxies for server 270 with
regard to the Client-Hello message issued by client 210.
Specifically, the SSI responds with Server-Hello (S-H), a
certificate (C) identifying SSI 250 with the same name by which
client 210 knows server 270, and Server-Hello-Done (SHD). The
client side intermediary decrypts this response with Kt and
forwards it to the client. The Server-Hello sent by SSI 250 may or
may not comprise the Server-Hello received by the SSI from server
270.
[0050] Client 210 responds with Client-Key-Exchange (CKE)
(including a client secret encrypted with an asymmetric key
extracted from the SSI's certificate), Change-Cipher-Specification
(CCS) and Finished (F). The CSI encrypts this response with Kt and
forwards it to SSI 250. The SSI completes the handshaking by
signaling CCS and F, which are decrypted by the CSI and delivered
to the client.
[0051] It can be seen now that at time sequence 286, server side
intermediary 250 has computed symmetric key Kc, which will be used
to encrypt communications from and to the client. Client 210
similarly possesses Kc at time sequence 288, at the completion of
the handshaking procedure with the SSI.
[0052] In the embodiment of the invention depicted in FIG. 2, after
SSI 250 computes a master secret and key Kc from the client's
secret, client-based seed and server-based seed, it forwards the
master secret and key Kc to the client side intermediary via their
secure tunnel. Thus, within a short time after the handshaking
between the client and the SSI, both the client and CSI 230 are
ready to use Kc, because the client can also compute the master
secret in the same manner as the SSI.
[0053] In one alternative implementation of this embodiment of the
invention, SSI 250 forwards only the master secret to CSI 230, and
the CSI computes Kc. In other implementations, other security may
be applied to protect the client secret and/or master secret in
transit between the SSI and the CSI.
[0054] In yet another alternative implementation, the master secret
(and, possibly key Kc) may be sent from the SSI to the CSI as part
of the message conveying Change-Cipher-Specification (CCS) and
Finished (F).
[0055] As will be seen below, possession of the master secret by
client side intermediary 230 can significantly expedite
establishment of a follow-on secure communication session that
employs the SSL reuse handshake process.
[0056] After time sequence 288, the client may now issue data
requests toward server 270. A client request is encrypted using Kc
and submitted to CSI 230, where it is decrypted using the same key.
The request is then encrypted using Kt, forwarded to SSI 250 and
decrypted with the same key. Finally, the SSI encrypts the request
with Ks and delivers it to server 270 for decryption and subsequent
action. The reverse process is then followed to securely deliver
the server's response to client 210.
[0057] Although not completely shown in FIG. 2, each CKE message is
encrypted with the public key of the server or other entity (e.g.,
SSI 250) to whom the CKE message is directed, and will be decrypted
using that entity's corresponding private key.
[0058] In FIG. 2, time sequences 282, 284, 286 and 288 are not
intended to represent the exact moments the indicated keys become
available for use by the corresponding communicants. Such moments
may occur before, after or even during the transmission or receipt
of messages represented by directed vectors proximate to these time
sequences.
[0059] FIG. 3 is a time sequence diagram demonstrating a reuse SSL
handshaking process for establishing a split-terminated secure
communication session between a client and a server with reduced
latency, according to some embodiments of the invention.
[0060] The illustrated reuse handshake procedure may be performed
after a full handshaking has been performed between the client and
the server (e.g., as described above in conjunction with FIG. 2),
but before the master secret has timed out or expired.
[0061] At time sequence 382, client 210 initiates such a follow-on
session. As described above, intermediaries 230, 250 have already
established a secure tunnel over the WAN connecting them, by
agreeing upon a symmetric key Kt, or will do so now.
[0062] In accordance with the SSL protocol, the client issues a
Client-Hello (C-H) message toward the server, which is intercepted
by client side intermediary 230. This Client-Hello message is
configured to request application of the reuse handshake procedure.
Illustratively, if the master secret has expired, the CSI may act
as if a full handshake is to be performed (e.g., as in FIG. 2), or
may reject the request.
[0063] Assuming the master secret has not timed out, because CSI
230 already possesses that secret from the preceding full SSL
handshake, it can immediately act as a proxy for server 270 and
return a message signaling Server-Hello (S-H), Server-Hello-Done
(SHD), Change-Cipher-Specification (CCS) and Finish (F). The client
responds with CCS and F.
[0064] Thus, in one embodiment of the invention depicted in FIG. 3,
the client can adopt Kc as the key for issuing secure data requests
very quickly, at time sequence 384, without awaiting a full
round-trip of communication with server 270 or SSI 250. Similarly,
CSI 230 adopts key Kc at time sequence 286, and can now receive and
act on a data request from the client.
[0065] More particularly, the new key Kc is generated from the
master secret computed in the previous full handshake, a new
client-based seed and a new server-based seed. The new client-based
seed is provided to CSI 230 in the Client-Hello message, and the
new server-based seed is received by the client as part of the
Server-Hello message sent by the CSI. Both entities can then apply
the transformation to produce a key block comprising the new key
Kc.
[0066] Meanwhile, in parallel with responding to the client's
Client-Hello message, the client side intermediary forwards a
special message or directive to server side intermediary 250 to
notify it of the new secure communication session.
[0067] In response to notification of the client's request for a
communication connection, SSI 250 performs an SSL reuse handshake
with server 270, in a manner similar to the reuse handshake
performed between client 210 and CSI 230. After this handshaking,
at time sequence 388, both the server and the SSI are ready to use
Ks to communicate securely. Alternatively, a full handshaking may
be performed, or a secure session may not even be established
between the SSI and the server.
[0068] In the illustrated embodiment of the invention, client 210
can begin issuing secure data requests toward server 270 rapidly,
possibly even sooner than it could have if CSI 230 and SSI 250 were
not interposed between the client and the server. In particular, in
the reuse handshake process promulgated in the SSL protocol
specification, the client must await the (S-H+SHD+CCS+F) message(s)
to arrive from the server before it can issue a data request.
[0069] It may be noted in FIG. 3 that the secure session
established between client 210 and CSI 230 is done using a master
secret derived from a client secret that the client never provided
directly to the CSI.
[0070] Any vulnerability of the client or client side intermediary
associated with allowing the CSI to know the master secret is
substantially mitigated by the fact that the secret is short-lived
(e.g., on the order of five minutes). Once the secret expires, the
vulnerability is eliminated. Because the CSI only possesses the
master secret (and not the server's (or SSI's) private key), it
cannot proxy for the server (or the SSI).
[0071] In FIG. 3, time sequences 382, 384, 386 and 388 are not
intended to represent the exact moments when the indicated keys
become available for use. Such moments may occur before, after or
even during the transmission or receipt of messages represented by
directed vectors proximate to these time sequences.
[0072] Network traces have shown that an SSL session opened with a
full handshake is, on average, followed by five subsequent SSL
sessions opened with reuse handshakes. Therefore, embodiments of
the invention described herein can serve to significantly reduce
the overall communication latency during consecutive data requests
and responses. And, in particular, when transaction accelerators or
other intermediaries are interposed in the client-server path of
communications, the latency reduction provided by these embodiments
of the invention can be even more substantial.
[0073] Characteristics of an end-to-end secure communication
session as described in the SSL protocol specification (without
interception by intermediate entities), and split-terminated secure
communication sessions as constructed in an embodiment of the
invention in which the methods of FIG. 2 (for full handshaking) and
FIG. 3 (for reuse handshaking) are combined, are summarized in
TABLE 1. Specifically, TABLE 1 indicates where session termination
is performed, where the necessary private key is stored, and
whether optimization can be performed on communications exchanged
via the indicated type of session.
TABLE-US-00001 TABLE 1 Termination Termination Private Key
Description (Full HS) (Reuse HS) Location Optimize? No Interception
Server Server Server No Migrate Master SSI CSI SSI Yes Secret to
CSI
[0074] TABLE 1 demonstrates that when a secure communication
protocol such as SSL is used to secure an end-to-end session
between a client and a server, without interception, all
termination (for both full and reuse handshaking processes) is
performed at the server. Further, the server holds the private
asymmetric key that corresponds to the public key used by the
client to secure the secret it submits as part of the full
handshaking process. And, of course, because no intermediaries are
present, no other entity intercepts and can optimize the
client-server communications.
[0075] In contrast, when a master secret is migrated to a client
side intermediary (e.g., CSI 230 of FIG. 2 and FIG. 3), the point
of termination of a session depends on the type of handshaking. For
full handshaking involving generation of a new master secret, a
server side intermediary will act, but for reuse handshaking in
which the previous master secret is reused, the client side
intermediary will act.
[0076] It is also noted that a private key is loaded at the SSI,
along with a digital certificate that allows the SSI to proxy for
the server for some operations. Finally, the intermediaries can be
configured to perform various types of optimization on
communications passing between the client and server.
[0077] In other embodiments of the invention, enhancements may be
made to the method of establishing split-terminated protocol
sessions described above in conjunction with FIG. 2.
[0078] FIG. 4 is a time sequence diagram demonstrating a full SSL
handshaking process for establishing a split-terminated secure
communication session between a client and a server with reduced
latency, according to some embodiments of the invention.
[0079] In one such embodiment, a digital certificate assigned to
server side intermediary 450 is provided to client side
intermediary 430, and may or may not be encrypted with key Kt. Less
communication across the WAN separating the SSI and CSI will
subsequently be necessary to establish client communication
sessions, because the CSI can perform some actions that would have
been performed by the SSI (or the server), such as responding to a
Client-Hello message. Reference may be made to FIG. 2 to observe
differences between these embodiments of the invention.
[0080] The SSI's certificate is transmitted to the CSI when client
410 initiates a session at time sequence 482, or at some earlier
time.
[0081] Upon receipt of the client's Client-Hello (C-H) message, the
client side intermediary proxies for the SSI and signals
Server-Hello (S-H), the SSI's certificate (C) and Server-Hello-Done
(SHD). Client 410 responds with Client-Key-Exchange (CKE), which is
encrypted with the public key specified in the SSI's certificate,
Change-Cipher-Specification (CCS) and Finish (F).
[0082] Because the CSI does not possess the SSI's private key in
this embodiment of the invention, it forwards a message comprising
CKE to SSI 450. It may or may not further encrypt the signal with
the intermediaries' shared key Kt.
[0083] The SSI decrypts the CKE message to derive the client's
secret, and generates and transmits the master secret to CSI 430
(encrypted with Kt). The CSI then completes the handshake procedure
with client 410 by sending Change-Cipher-Specification (CCS) and
Finish (F). Thus, at time sequence 484, both client 410 and CSI 430
are ready to use key Kc.
[0084] Meanwhile, after the server side intermediary receives the
CKE message and learns of the new session, it initiates a secure
session with server 470 as described above in conjunction with FIG.
2. Thus, at time sequence 486 both SSI 450 and server 470 are ready
to use key Ks. In an alternative implementation, CSI 430 may notify
SSI 450 of the new session earlier in the process, such as upon
receipt of the Client-Hello message.
[0085] After deriving key Kc, the client can issue a data request
for conveyance to the server via the intermediaries. The process by
which the request and corresponding response are encrypted and
decrypted may be similar to the process described above in
conjunction with FIG. 2.
[0086] Although not completely shown in FIG. 4, each CKE message is
encrypted with the public key of the server or other entity (e.g.,
CSI 430, SSI 450) to whom the CKE message is directed, and will be
decrypted using that entity's corresponding private key.
[0087] With regard to the full handshaking procedure depicted in
FIG. 2, it can be seen that in FIG. 4 one full round-trip across
the WAN is eliminated, thereby reducing the overall latency
encountered in receiving and responding to a client data
request.
[0088] TABLE 2 is a version of TABLE 1 updated to reflect
characteristics of an embodiment of the invention in which an SSI
certificate is migrated to the CSI. In this embodiment, the method
of FIG. 4 is used for full handshaking and the method of FIG. 3 is
used for reuse handshaking.
TABLE-US-00002 TABLE 2 Termination Termination Private Key
Description (Full HS) (Reuse HS) Location Optimize? No Interception
Server Server Server No Migrate Master SSI CSI SSI Yes Secret to
CSI Migrate SSI CSI CSI SSI Yes Certificate to CSI
[0089] FIG. 5 is a time sequence diagram demonstrating a full SSL
handshaking process for establishing a split-terminated secure
communication session between a client and a server with further
reduced latency, according to some embodiments of the
invention.
[0090] In one such embodiment, a digital certificate assigned to
server side intermediary 550 is provided to client side
intermediary 530, as well as the corresponding private key. The
private key is encrypted with Kt; the certificate may or may not be
encrypted. Even less communication across the WAN separating the
SSI and CSI is now required because the CSI can decrypt the
client's CKE message. Reference may be made to FIG. 2 and FIG. 4 to
observe differences between these embodiments of the invention.
[0091] In particular, it can be seen in FIG. 5 that another full
round-trip across the WAN is avoided. However, the client side
intermediary may, at some point in the handshaking process with
client 510, advise the server side intermediary so that it can
initiate a secure session with server 570.
[0092] Alternatively, if communications between SSI 550 and the
server need not be protected, the SSI need not be advised of the
new secure session until a data request from the client is
forwarded from CSI 530.
[0093] Although not completely shown in FIG. 5, each CKE message is
encrypted with the public key of the server or other entity (e.g.,
CSI 530, SSI 550) to whom the CKE message is directed, and will be
decrypted using that entity's corresponding private key.
[0094] Illustratively, in the embodiment of the invention depicted
in FIG. 5, the private key may be protected on the client side
intermediary by restricting its storage to transient memory. By
preventing it from being written to any permanent storage device,
its vulnerability is limited.
[0095] TABLE 3 is a version of TABLE 2 that has been updated to
reflect characteristics of an embodiment of the invention in which
an SSI certificate and corresponding private key are migrated to
the CSI. In this embodiment, the method of FIG. 5 is used for full
handshaking and the method of FIG. 3 is used for reuse
handshaking.
TABLE-US-00003 TABLE 3 Termination Termination Private Key
Description (Full HS) (Reuse HS) Location Optimize? No Interception
Server Server Server No Migrate Master SSI CSI SSI Yes Secret to
CSI Migrate SSI CSI CSI SSI Yes Certificate to CSI Migrate Private
CSI CSI CSI Yes Key to CSI (Transient)
[0096] TABLE 4 reports the latency advantages of methods of the
invention described herein, wherein either one or more of a client
secret, SSI certificate and private key are migrated to a client
side intermediary. The measure of latency employed in TABLE 4 is
expressed in round-trip-times (RTT) across the WAN separating the
network intermediaries because the time needed to convey a
communication between the communication endpoints is dominated by
the latency of the WAN.
TABLE-US-00004 TABLE 4 Total RTTs for typical Full HS Reuse HS
browser interaction: Description WAN RTTs WAN RTTs 1 full HS + 5
reuse HS No Interception 3 2 13 Migrate Master 3 1 8 Secret to CSI
Migrate SSI 2 1 7 Certificate to CSI Migrate Private 1 1 6 Key to
CSI
[0097] TABLE 4 reveals that in the control case in which no
interception is performed (i.e., the client establishes secure
sessions directly with the server, with no split-terminated
sessions), three round-trip-times across the WAN are needed to
complete a single session (using a full handshake process)
involving a single request (e.g., an HTTPS GET) and one response.
Two round-trips are needed to complete a reuse session (with a
reuse handshake process).
[0098] With no interception, for a typical browser pattern of
interaction with the server, defined as involving a first secure
session requiring full handshaking, followed by five follow-on
secure sessions implementing reuse handshaking, a total of 13 WAN
RTTs is required.
[0099] It can be seen that the methods of split-termination of
secure protocol communication sessions described herein permit
significant reductions in latency, especially for the typical
pattern of browser interaction. Even if a browser's pattern of
interaction is less efficient (i.e., fewer reuse sessions following
a full handshaking process), overall latency can still be
reduced.
[0100] The optimization of communications that the intermediaries
provide may reduce end users' latency even further, but are not
reflected in TABLE 4. However, it is assumed that latency across
LANs is negligible in comparison to WAN latency.
[0101] The environment in which a present embodiment of the
invention is executed may incorporate a general-purpose computer or
a special-purpose device such as a hand-held computer. Details of
such devices (e.g., processor, memory, data storage, display) may
be omitted for the sake of clarity.
[0102] The data structures and code described in this detailed
description are typically stored on a computer-readable storage
medium, which may be any device or medium that can store code
and/or data for use by a computer system. The computer-readable
storage medium includes, but is not limited to, volatile memory,
non-volatile memory, magnetic and optical storage devices such as
disk drives, magnetic tape, CDs (compact discs), DVDs (digital
versatile discs or digital video discs), or other media capable of
storing computer-readable media now known or later developed.
[0103] The methods and processes described in the detailed
description can be embodied as code and/or data, which can be
stored in a computer-readable storage medium as described above.
When a computer system reads and executes the code and/or data
stored on the computer-readable storage medium, the computer system
performs the methods and processes embodied as data structures and
code and stored within the computer-readable storage medium.
[0104] Furthermore, the methods and processes described below can
be included in hardware modules. For example, the hardware modules
may include, but are not limited to, application-specific
integrated circuit (ASIC) chips, field-programmable gate arrays
(FPGAs), and other programmable-logic devices now known or later
developed. When the hardware modules are activated, the hardware
modules perform the methods and processes included within the
hardware modules.
[0105] The foregoing descriptions of embodiments of the invention
have been presented for purposes of illustration and description
only. They are not intended to be exhaustive or to limit the
invention to the forms disclosed. Accordingly, many modifications
and variations will be apparent to practitioners skilled in the
art. The scope of the invention is defined by the appended claims,
not the preceding disclosure.
* * * * *