Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20020035681
Kind Code
A1
Maturana, Guillermo ; et al.
March 21, 2002
Strategy for handling long SSL messages
Abstract
Embodiments of the present invention provide method and apparatus that encrypt/decrypt messages sent over a network rapidly, and which do not require large amounts of computational or memory resources. In particular, one embodiment of the present invention is a method of providing security in a communication between a first end and a second end involving a security layer and a transport layer, wherein at some security layer messages sent from the first end are long security layer messages, which method includes steps of: (a) identifying a long security layer message in a transport layer segment received from the first end, decrypting security layer information contained in the transport layer segment, and buffering decrypted security layer information; (b) identifying the end of the long security layer message, and verifying the long security message; and (c) sending the decrypted long security layer message to the second end.
Inventors:
Maturana; Guillermo
(Berkeley, CA)
, Naik; Ashish N.
(San Jose, CA
)
Correspondence Name and Address:
25680 FERNHILL DRIVE
MICHAEL B. EINSCHLAG, ESQ.
LOS ALTOS HILLS
CA
94024
US
Series Code:
792964
Filed:
February 26, 2001
U.S. Current Class:
713/151;
713/200
U.S. Class at Publication:
713/151;
713/200
Intern'l Class:
H04L 009/00
Claims
What is claimed is:
1. A method of providing security in a communication between a first end and a second end involving a security layer and a transport layer, wherein at some security layer messages sent from the first end are long security layer messages, which method comprises steps of: identifying a long security layer message in a transport layer segment received from the first end, decrypting security layer information contained in the transport layer segment, and buffering decrypted security layer information; identifying the end of the long security layer message, and verifying the long security message; and sending the decrypted long security layer message to the second end.
2. The method of claim 1 wherein the step of verifying comprises determining a running verification computation for each transport segment comprising the long security layer message.
3. The method of claim 2 wherein the method further comprises the steps of maintaining: (a) a total expected length of the long security layer message; (b) a length up to a last fully processed block of the long security layer message; (c) a partial signature as of the last processed block of the long security layer message; (d) a length of the last incomplete block of the long security layer message; (e) the last incomplete block; and (f) a cipher state corresponding to a next expected block.
4. The method of claim 1 wherein window size information is saved for each transport layer segment received from the first end and the second end.
5. The method of claim 4 wherein the window size is updated on all Acks.
6. The method of claim 1 which further comprises a step of sending an inhibitor message to the first end to inhibit the first end from sending further data to the second end.
7. The method of claim 6 wherein the inhibitor message comprises a window size of zero.
8. The method of claim 1 wherein Acks contained in the long security layer message are sent to the second end.
9. The method of claim 1 which further comprises sending Acks to the first end as the transport layer segments are received.
10. The method of claim 9 wherein the Acks contain a current window size offered by the second end.
11. The method of claim 1 which further comprises sending delayed Acks to the first end for the transport layer segments received.
12. The method of claim 1 wherein the step of sending the decrypted long security layer message comprises sending the decrypted long security layer message after the second end has caught up to a beginning of the long security layer message.
Description
[0001] This is a continuation-in-part of a patent application entitled "State Transition Strategy for Handling Secure Communications," Ser. No. 09/630330, filed Jul. 31, 2000.
[0002] This patent application is related to a patent application entitled "Strategy for Handling Dropped Data in Secure Communications" which was filed the same date, and which is commonly owned.
TECHNICAL FIELD OF THE INVENTION
[0003] The present invention pertains to method and apparatus for handling secure communications. In particular, some embodiments of the present invention relate to method and apparatus for handling secure communications in a non-proxy mode. In further particular, some embodiments of the present invention pertain to method and apparatus for Secure Sockets Layer ("SSL") handling of secure communications in a nonproxy mode.
BACKGROUND OF THE INVENTION
[0004] A well known set of protocols, known in the art as Transmission Control Protocol/Internet Protocol ("TCP/IP") protocols, govern most of an interconnected public network known as the Internet. The TCP/IP protocols conform to an Open Systems International ("OSI") layered network description wherein: (a) layer 1 is a physical layer that transmits bits of information across a link (it deals with problems such as size and shape of connectors, assignment of finctions to pins, conversion of bits to electrical signals, bit-level-synchronization, and so forth); (b) layer 2 is a data link layer that is responsible for transmitting chunks of information across a link (it deals with problems such as checksumming to detect data corruption, coordinating the use of shared media, as in a local area network ("LAN"), and addressing--"Ethernet" is one well known example of a layer 2 protocol); (c) layer 3 is a network layer that enables any pair of systems in the network to communicate with each other (it deals with problems such as route calculation, packet fragmentation and re-assembly when different links in the network have different maximum packet sizes, and congestion control--Internet Protocol ("IP") is perhaps the most well known example of a layer 3 protocol); (d) layer 4 is a transport layer that establishes a reliable communication stream between a pair of systems (it deals with errors that can be introduced by the network layer, i.e., layer 3, such as lost packets, duplicated packets, packet reordering, and fragmentation and re-assembly so that the user of the transport layer can deal with larger-size messages, and so that less efficient network layer fragmentation and re-assembly might be avoided-Transmission Control Protocol ("TCP") is perhaps the most well known example of a layer 4
protocol); and (e) layers 5-7 have less clear distinctions in practical network implementations (collectively, layers 5-7 cover the functionality of an operating system and applications, and as such, are much less standardized than layers 1-4). These concepts are described in a book entitled "TCP/IP Illustrated, Volume 1-The Protocols" by W. Richard Stevens, published by Addison-Wesley, 1994, and a book entitled "Interconnections, Second Edition Bridgers, Routers, Switches, and Internetworking Protocols" by Radia Perlman, published by Addison-Wesley, 1999.
[0005] As is well known to those of ordinary skill in the art, a transport layer, for example and without limitation, a layer 4 protocol such as TCP, deals with a segment (a TCP segment) that comprises a transport (TCP) header and application data, which application data will be referred to herein as a message or a payload. The application data typically includes user data and an application header. As is further well known to those of ordinary skill in the art, a network layer, for example and without limitation, a layer 3 such as IP, deals with a datagram that comprises a network (IP) header and the TCP segment. As is well known to those of ordinary skill in the art, due to restrictions of a layer 2 implementation, a layer 3 datagram must sometimes be broken up into smaller units of data, i.e., fragments, each of which must be sent separately across the physical wire. This might happen, for example, if an IP datagram were too large to be transmitted over a particular layer 2
link. In this case, each fragment would have a different IP header. Each such unit of transfer at the network layer level will be referred to herein as a packet. Lastly, a link layer, for example and without limitation, a layer 2 protocol such as Ethernet, deals with a frame that comprises a (Ethernet) header, an IP datagram, and a (Ethernet) trailer.
[0006] In a TCP/IP connection between a client and a server across a network such as the Internet, information flow is bidirectional, i.e., each unit of data sent across the network has a "sender" (for example, either a client or a server) and a "receiver" (for example, either the server or the client, respectively). As is well known to those of ordinary skill in the art, some characteristics of the transmitted data are linked to the client or server role in a transmission, regardless of the direction of information transmission, and other characteristics of the transmitted data are linked to the sender or receiver role, regardless of whether the sender was the client or the server.
[0007] The Internet is presently being used extensively for eCommerce, stock transactions, and other transactions that require security and privacy. To provide such security and privacy, most commercial websites use a security technology provided by the Secure Sockets Layer ("SSL") protocol.
[0008] SSL is a separate protocol used just for security that is inserted between TCP and the Hypertext Transfer Protocol ("HTTP"). By acting as a new protocol, SSL requires very few changes in protocols existing above and below it. In particular, an HTTP application interfaces with SSL nearly the same way it would with TCP in the absence of SSL. And, as far as TCP is concerned, SSL is just another application using its services. Thus, SSL provides a standardized method of adding cryptographic security functions to a TCP-based application such as a web browser. See a book by Stephen Thomas entitled "SSL and TLS Essentials, Securing the Web," published by John Wiley & Sons, Inc., 2000.
[0009] The Internet Engineering Task Force ("IETF" ietf. org) has taken the SSL specification and standardized it in the Transport Layer Security ("TLS") open standard. Further, the Wireless Application Protocol ("WAP") standards group has formed a variant of the TLS standard called Wireless Transport Layer Security ("WTLS"), with some additional features for the wireless environment.
[0010] In this patent specification, the term SSL refers to any member of this encryption family including, but not limited to, currently popular family members SSL 2.0, SSL 3.0, TLS 1.0, and WTLS 1.1. In addition, in this patent specification, the term Transaction Security refers to the SSL family of encryption standards, as opposed to Network Security as implemented by the IPSec standard. In particular, as used in this patent specification, Transaction Security is performed above layer 4 in a layer 4/layer 3 stack (for example, a TCP/IP stack), whereas Network Security is performed at layer 3 or below.
[0011] The SSL protocol defines two different roles for communicating parties. One system is always a client, while the other is a server; the SSL protocol requires the two systems to behave differently. The client is always the system that initiates a secure communication, and the server responds to the client's request. Since the client initiates a communication, it has the responsibility of proposing a set of SSL options to use for the exchange. The server selects from the client's proposed options, deciding which one the two systems will actually use. Although the final decision rests with the server, the server can only choose from among those options that the client has originally proposed.
[0012] Whenever SSL clients and servers communicate, they do so by exchanging SSL messages. As is well known to those of ordinary skill in the art, such SSL messages include, in alphabetic order: (a) "Alert," a message that informs the other party of a possible security breach or communication failure; (b) "ApplicationData," a message that refers to actual information exchanged by the two parties exchange that is encrypted, authenticated, and/or verified by SSL; (c) "Certificate," a message that carries the sender's public key certificate; (d) "CertificateRequest," a message from the server requesting the client to provide its public key certificate; (e) "CertificateVerify," a message from the client verifying it knows the private key corresponding to its public key certificate; (f) "ChangeCipherSpec," a message to begin using agreed-upon security services (such as encryption); (g) "ClientHello," a message from the client indicating the security services it desires and is capable of supporting; (h) "ClientKeyExchange," a message from the client carrying cryptographic keys for the communications; (i) "Finished," a message indicating that all initial negotiations are complete and secure communications have been established; "HelloRequest," a message from the server requesting the client to start (or restart) the negotiation process; (k) "ServerHello," a message from the server indicating the security services that will be used for the communications; "ServerHelloDone," a message from the server that it has completed all its requests of the client for establishing communications; and "ServerKeyExchange," a message from the server carrying cryptographic keys for the communications.
[0013] The SSL protocol does not exist in isolation. Rather, it depends on additional, lower-level protocols to transport its messages between peers. In all practical implementations, the SSL protocol relies on the TCP protocol. It is critical for the SSL protocol to receive TCP segments in the correct sequence, so it relies on TCP to deliver segments in order. SSL can determine the beginning and end of its own messages without assistance from the transport layer. To mark these beginnings and endings, SSL puts its own explicit length indicator in every message. This explicit length indicator enables SSL to combine multiple SSL messages into single TCP segments. This conserves network resources, and increases efficiency of the SSL protocol.
[0014] In one example of an SSL transmission across a TCP/IP network such as the Internet, a client (for example, a web browser on a personal computer) runs an application that generates an SSL message to be sent to a server (for example, an Internet web site running on the server). To send the message, the application sends the SSL message to an SSL handler on the client side of the transmission. The SSL handler on the client side sends a complete SSL message to a TCP/IP stack routine running on the client side of the transmission, which TCP/IP stack routine manages a layer 4 queue and a layer 3 queue. The client side TCP/IP stack routine sends the SSL message to the server. Depending on the particular implementation of the TCP/IP stack routine, the SSL message may be broken up into one or more IP datagrams that are sent individually through a network interface to the Internet. In a typical case, each IP datagram is a single packet that is routed independently across the Internet using standard layer 2 and layer 3 switching technology that is well known to those of ordinary skill in the art. In this typical case, each packet arrives at a server network interface card; and is detected by a TCP/IP stack routine running on the server side of the transmission. As is well known in the art, the server side TCP/IP stack routine detects the arrival of each packet, and assembles the packets, in order, to form the original TCP message. Then, the TCP message is passed to an SSL handler on the server side of the transmission. The SSL handler on the server side waits until the TCP/IP stack routine running on that machine has received the complete SSL message.
[0015] As is well known in the art, the SSL handlers on both the client and server side of the communication are unaware of the details of layer 4 and below transmission, including, for example, the number of packets sent, the order in which the packets were sent, the transmission protocols used for the transmission, the occurrence of any dropped packets, any required re-sends of those packets, and so forth.
[0016] FIG. 1 shows a diagram of a standard transmission between a client and a server over a network in which agent 103 has been inserted to perform an encryption and decryption function according to an SSL family of security protocols. As shown in FIG. 1, network 102 is a network, for example and without limitation, a public network commonly known as the Internet, and network 104 is a network, for example and without limitation, a private network, most often existing inside a physically secure building such as, for example and without limitation, a co-location facility. In operation, agent 103 receives encrypted traffic sent by client 101 through network 102, decrypts it, and sends it through network 104 to server 105. Conversely, whenever server 105 sends data through network 104 to agent 103, agent 103 encrypts the data, and sends it through network 102 to client 102. Note that unencrypted (i.e., "plaintext") data appears on network 104. The function of agent 103 was historically integrated into an application running on server 105, for example, an Apache web server, but for performance reasons (due to computationally intense cryptography), the function of agent 103 was separated in the manner shown in FIG. 1.
[0017] In current implementations of agent 103 performing SSL family functions, there is a high performance and memory requirement for agent 103 because the connection from agent 103 to client 101, and the connection from agent 103 to server 105 are separate TCP/IP connections. This arrangement is referred to in the art as a "proxy-mode" SSL connection because agent 103 implements a fully-functional TCP/IP stack in order to maintain these two connections. The performance requirements of the complete system are high, and the total number of required, simultaneously active connections is high.
[0018] FIG. 2 shows a schematic diagram of conventional information flow from sender 201 to receiver 203. Note that sender 201 may be either a client or a server in a network relationship. As shown in FIG. 2, SSL message handler 210 in sender 201 forms an SSL message, and sends the SSL message to TCP/IP stack routine 206 of sender 201 (stack routine 206 is shown schematically to comprise a layer 4 queue structure and a layer 3
queue structure). TCP/IP stack routine 206 transmits packets 204 out of a network interface (typically, an Ethernet adapter card) at sender 201
onto a network. Packets 204 are received by a network interface (typically, an Ethernet adapter card) at prior art agent 202, and they are assembled and interpreted by TCP/IP stack routine 207 running on agent 202 (stack routine 207 is shown schematically to comprise a layer 4
queue structure and a layer 3 queue structure). TCP/IP stack routine 207
combines packets 204 and resulting TCP segments to form the complete SSL message, and passes the SSL message to SSL function 212 for encryption or decryption (depending on whether the sender is a server or a client, respectively). Next, SSL function 212 sends the resulting encrypted/decrypted message to TCP/IP stack routine 208 (stack routine 208 is shown schematically to comprise a layer 4 queue structure and a layer 3 queue structure). In practice, TCP/IP stack routine 208 may also serve as TCP/IP stack routine 207. TCP/IP stack routine 208 transmits packets 205 out of a network interface at agent 202 onto a network. Packets 205 are received by a network interface at receiver 203, and they are assembled and interpreted by TCP/IP stack 209 running on receiver 203
(stack routine 209 is shown schematically to comprise a layer 4 queue structure and a layer 3 queue structure). TCP/IP stack routine 209
combines packets 205 and resulting TCP segments to form a complete SSL message 211. Note that in this prior art implementation, one or two complete TCP/IP stacks must be running on agent 202 to implement the SSL functionality. Also, because there may be many concurrent SSL sessions being handled, and because packets for each session (shown as packets 204
and packets 205 in FIG. 2) are interleaved with those from other sessions, there must be a large amount of memory present at agent 202 to support the many concurrent sessions.
[0019] At present, on a client, SSL is embedded in browsers such as, for example, Netscape and Internet Explorer. Every time a secure site is accessed by such a browser, an SSL session with a server is established. Currently, 5 to 10% of eCommerce traffic is encrypted via SSL, and for a site like eTrade, 100% of registered user service traffic is encrypted. Servers that support these sites can handle thousands of standard http (non-encrypted) transactions per second, but when a secure transaction is needed there is substantial overhead for the server. The overhead comes from establishing an SSL session (this involves thousands of operations associated with cryptography), and from encrypting/decrypting each message during an SSL session. The overhead is such that servers' throughput is reduced significantly.
[0020] As discussed above, there are products currently on the market to accelerate SSL transactions, which products decrypt an incoming transaction, and send it to the server "in the clear" (i.e., un-encrypted). Intel offers a "iPivot" box that is claimed to process 200
SSL messages per second, and to increase server throughput by a factor of 50. IBM offers a computer system hosting Rainbow cards that claims to provide 200 SSL messages per second per card. In spite of the above offerings, securing Internet traffic remains inefficient.
[0021] As one can readily appreciate from the above, a need exists in the art for method and apparatus that encrypt/decrypt messages sent over a network rapidly, and which do not require large amounts of computational or memory resources.
SUMMARY OF THE INVENTION
[0022] Embodiments of the present invention advantageously satisfy the above-identified need in the art and provide method and apparatus that encrypt/decrypt messages sent over a network rapidly, and which do not require large amounts of computational or memory resources.
[0023] In particular, one embodiment of the present invention is a method of providing security in a communication between a first end and a second end involving a security layer and a transport layer, wherein at some security layer messages sent from the first end are long security layer messages, which method comprises steps of: (a) identifying a long security layer message in a transport layer segment received from the first end, decrypting security layer information contained in the transport layer segment, and buffering decrypted security layer information; (b) identifying the end of the long security layer message, and verifying the long security message; and (c) sending the decrypted long security layer message to the second end.
BRIEF DESCRIPTION OF THE FIGURE
[0024] FIG. 1 shows a diagram of a standard configuration of a client-server connection using a network in which an agent has been inserted to perform an encryption and decryption function according to an SSL family of security protocols;
[0025] FIG. 2 shows a schematic diagram of conventional information flow from a sender to a receiver where an agent has been inserted to perform an encryption and decryption function according to an SSL family of security protocols;
[0026] FIG. 3 shows a schematic diagram of information flow from a sender to a receiver in accordance with an embodiment of the present invention;
[0027] FIG. 4 shows a block diagram of an embodiment of an inventive, nonproxy-mode SSL system;
[0028] FIG. 5 shows a block diagram illustrating how an embodiment of the present invention changes seq and ack for messages transmitted between a client and a server;
[0029] FIG. 6 shows, in pictorial form, session messages that are transferred between a client, an inventive, non-proxy-mode SSL system, and a server;
[0030] FIG. 7 shows a flowchart of operation for the embodiment shown in FIG. 4; and
[0031] FIG. 8 shows a detailed portion of the flowchart shown in FIG. 7.
DETAILED DESCRIPTION BOLD layer numbers but not others
[0032] FIG. 3 shows a schematic diagram of information flow from sender 201 to receiver 203 in accordance with one embodiment of the present invention. Note that sender 201 may be either a client or a server in a network relationship. As shown in FIG. 3, SSL message handler 210 in sender 201 forms an SSL message, and sends the SSL message to TCP/IP stack routine 206 of sender 201 (stack routine 206 is shown schematically to comprise a layer 4 queue structure and a layer 3 queue structure). TCP/IP stack routine 206 transmits layer 3 packets 204 out of a network interface (typically, an Ethernet adapter card) at sender 201 onto a network, for example and without limitation a public network such as the Internet. Layer 3 packets 204 are received by a network interface (typically, an Ethernet adapter card) at inventive, non-proxy agent 301. In accordance with this embodiment of the present invention, layer 3
packets 204 arriving at the network interface (not shown) of agent 301
are processed individually to enable secure transmission (for example and without limitation, they are processed to perform encryption/decryption), and sent out onto a network, for example and without limitation, a private network, as layer 3 packets 302. As will be described in detail below, layer 3 packets 302 are not necessarily identical to layer 3
packets 205 described above in the Background of the Invention in conjunction with FIG. 2. As was discussed above, in the Background of the Invention, since SSL functionality is not sensitive to the operation of layers 4 and below, the fact that layer 3 packets 302 have different characteristics than layer 3 packets 205 does not impact SSL messages. Layer 3 packets 302 are received by a network interface at receiver 203, and they are assembled and interpreted by TCP/IP stack 209 running on receiver 203 (stack routine 209 is shown schematically to comprise a layer 4 queue structure and a layer 3 queue structure). TCP/IP stack routine 209 combines layer 3 packets 302 and resulting TCP segments to form a complete SSL message 211, which message 211 is identical to message 211 obtained by the prior art implementation described in the Background of the Invention in conjunction with FIG. 2.
[0033] In accordance with this embodiment of the present invention, inventive, non-proxy agent 301 performs the following functions: (a) passes TCP connection establishment messages from sender to receiver and vice versa (hence the designation non-proxy agent), but records some of the exchanged information to provide a "quasi-three-way" handshake; (b) intercepts SSL session messages, and responds to the sender to: (i) set up an SSL session between the sender and inventive, non-proxy agent 301
by handling the SSL handshake and (ii) terminate an SSL session between the sender and inventive, non-proxy agent 301 in response to SSL session termination messages; (c) intercepts bulk data transfer SSL messages from the sender to the receiver and decrypts/encrypts messages (from client/server, respectively); and (d) passes TCP connection termination messages from sender to receiver and vice versa.
[0034] FIG. 6 shows, in pictorial form, session messages that are transferred among a client, an inventive, non-proxy-mode SSL system, and a server, As one can readily appreciate from this, TCP/IP connection establishment messages (which messages will be described in detail below) are shown to flow between the client and the server through the inventive, non-proxy-mode agent (in a manner that will be described in detail below) during phase 3000. SSL handshake messages (which messages will be described in detail below) are shown to flow between the client and the inventive, non-proxy-mode agent (in a manner that will be described in detail below) during phase 3010. Bulk encryption/decryption messages are shown to flow between the server and the client and between the client and the server, respectively (which messages will be described in detail below) through the inventive, non-proxy-mode agent (in a manner that will be described in detail below) during phase 3020. Lastly, TCP/IP connection termination messages (which messages will be described in detail below) are shown to flow between the client and the server through the inventive, non-proxy-mode agent (in a manner that will be described in detail below) during phase 3030.
[0035] In accordance with this embodiment of the present invention, in essence, inventive, non-proxy agent 301 receives all incoming network traffic, and intercepts SSL session-related traffic. In addition, in accordance with this embodiment, inventive, non-proxy agent 301
implements a higher-level security protocol (for example and without limitation, an SSL family security protocol) on a packet-by-packet basis (for example and without limitation, on a layer 3 packet by layer 3
packet basis). In the prior art, security protocols are typically associated with lower-layer security protocols such as IPSec (a layer 3
security protocol), or PPTP (a layer 2 security protocol). Advantageously, as will be described in detail below, a key to the speed and memory-efficiency of embodiments of the present invention in handling SSL transactions is that such embodiments do not terminate a TCP connection from either a client or a server as is believed to be the case for prior art "proxy" mode firewalls such as Intel's iPivot box, and so forth, Instead, as was described above in conjunction with FIG. 3, inventive, non-proxy agent can act "like a router," and process each layer 3 (for example, IP layer) packet independently. Advantageously, embodiments of the present invention provide order-of-magnitude improvements in processing speed and memory requirements over those available in the prior art.
[0036] For the sake of understanding embodiments of the present invention, the following terminology will be used: incoming traffic refers to traffic sent from a client to a server (i.e., an "inbound" packet refers to a packet sent from a client to a server) and outgoing traffic refers to traffic from the server to the client (i.e., an "outbound" packet refers to a packet sent from the server to the client).
[0037] Before discussing specific details of an embodiment of the present invention, the following overview will be given to enable one to better understand how such an embodiment operates.
[0038] It is helpful to understand that, in a typical communication, inbound traffic is light, i.e., just GET and POST requests from a browser (for example, "give me my checking account history"), and outbound traffic is heavy, i.e., lots of actual HTML page data.
Pre-Filter
[0039] Frames are input to network interfaces at an embodiment of the inventive, non-proxy agent where a frame comprises, for example and without limitation: (a) an Ethernet header; (b) an IP header; (c) a TCP header; (d) an SSL header; (e) data; and (f) an Ethernet trailer. In accordance with this embodiment of the present invention, the inventive, non-proxy agent examines frames to "pre-filter" them. For example, this "prefilter" step entails carrying out functions such as, for example, and without limitation: (a) evaluating the checksum of the link (for example, Ethernet) layer, the IP layer and the TCP layer; (b) looking for logical errors (such as, for example, inconsistent frame length, IP length, and TCP header length); (c) determining whether a frame is a non-IP frame; (d) determining whether the frame is a non-SSL frame; and (e) determining whether a frame corresponds to a TCP frame. All of these individual "pre-filter" functions can be carried out using any one of a number of methods that are well known to those of ordinary skill in the art.
[0040] In accordance with this embodiment of the present invention, if the frame (i.e., the link layer) contains, for example and without limitation, a logical error (for example, an incomplete packet as determined by an analysis of the link layer header) or an improper checksum, the frame may, for example and without limitation, be dropped (i.e., no further processing is carried out, and the frame is not forwarded). If the frame does not contain an IP packet, or a TCP segment, or does not pertain to SSL, it is forwarded to the receiver without any further action being taken.
TCP Connection Establishment and Termination
[0041] In general, as set forth in the following quote from page 231 of the book entitled "TCP/IP Illustrated, Volume 1-The Protocols" by W. Richard Stevens, published by Addison-Wesley, 1994:
[0042] 1. The requesting end (normally called the client) sends a SYN segment specifying the port number of the server that the client wants to connect to, and the client's initial sequence number (ISN, 1415531521 in this example). This is segment 1.
[0043] 2. The server responds with its own SYN segment containing the server's initial sequence number (segment 2). The server also acknowledges the client's SYN by ACKing the client's ISN plus one. A SYN consumes one sequence number.
[0044] 3. The client must acknowledge this SYN from the server by ACKing the server's ISN plus one (segment 3).
[0045] These three segments complete the connection establishment. This is often called the three-way handshake.
[0046] In accordance with one embodiment of the present invention, if a frame relates to TCP connection establishment, the inventive, non-proxy agent will forward the frame to the receiver, but will also record certain TCP information relating to the TCP connection and its establishment.
[0047] Each TCP segment contains a 16-bit source port number and a 16-bit destination port number to identify the sending and receiving applications. These two values, along with a 32-bit source IP address and a 32-bit destination IP address in the IP header, uniquely identify each TCP connection.
[0048] Thus, for a SYN TCP message (which TCP message is typically sent from the client to the server, and which TCP message signals the start of the establishment of a TCP connection), the recorded TCP information in general includes, for example and without limitation, a 16-bit source port number (from the TCP header), a 16-bit destination port number (from the TCP header), a 32-bit source IP address (from the IP header), a 32-bit destination IP address (from the IP header), and an initial seq number chosen by the host (for example, the client) for the connection, for example, X. As is well known to those of ordinary skill in the art, "seq" refers to a 32-bit TCP sequence number in the TCP header of a TCP segment, and "ack" refers to a 32-bit acknowledgment number in the TCP header of a TCP segment. Seq denotes the byte number in the TCP message that corresponds to the first byte in the data portion of the transmitted segment), and ack denotes the byte number in the TCP message that the recipient expects to receive as the first byte of the data portion of the next TCP segment.
[0049] In response to the SYN TCP connection establishment message from the client, the server will respond with a SYN-ACK TCP message. In this case, the inventive, non-proxy agent will also forward the frame to the client, but will also record certain TCP information for the SYN-ACK TCP message (which TCP message is typically sent from the server to the client), such recorded TCP information includes, for example and without limitation, an initial seq number chosen by the server for the connection, for example, Y, and an ack number X+1. The 16-bit source port number (from the TCP header), the 16-bit destination port number (from the TCP header), the 32-bit source IP address (from the IP header), and the 32-bit destination IP address (from the IP header) of the SYN-ACK TCP message should agree with that stored for the corresponding SYN TCP message because those parameters uniquely identify the TCP connection.
[0050] In response to the SYN-ACK TCP message, the client will respond with an ACK message. In this case, the inventive, non-proxy agent will forward the frame to the server, but will also record certain TCP information for the ACK TCP message, such TCP information includes, for example and without limitation, an ack number Y+1.
[0051] In general, as set forth in the following quote from page 233 of the book entitled "TCP/IP Illustrated, Volume 1-The Protocols" by W. Richard Stevens, published by Addison-Wesley, 1994:
[0052] While it takes three segments to establish a connection, it takes four to terminate a connection. This is caused by TCP's half-close. Since a TCP connection is full-duplex . . . , each direction must be shut down independently. The rule is that either end can send a FIN when it is done sending data. When a TCP receives a FIN, it must notify the application that the other end has terminated that direction of data flow. The sending of a FIN is normally the result of the application issuing a close.
[0053] The receipt of a FIN only means there will be no more data flowing in that direction. A TCP can still send data after receiving a FIN. . . .
[0054] We say that the end that first issues the close (e.g., sends the first FIN) performs the active close and the other end (that receives this FIN) performs the passive close. . . .
[0055] When the server receives the FIN, it sends back an ACK of the received sequence number plus one (segment 5). A FIN consumes a sequence number, just like a SYN. At this point the server's TCP also delivers an end-of-file to the application (the discard server). The server then closes its connection, causing its TCP to send a FIN (segment 6), which the client TCP must ACK by incrementing the received sequence number by one (segment 7).
[0056] In accordance with one embodiment of the present invention, if a frame relates to TCP connection termination, the inventive, non-proxy agent will forward the frame, for example, to the server, but will also record certain TCP information for a FIN TCP message which signals the end of a TCP connection. Thus, for a FIN TCP message, the recorded TCP information includes, for example and without limitation, the 16-bit source port number (from the TCP header), the 16-bit destination port number (from the TCP header), the 32-bit source IP address (from the IP header), and the 32-bit destination IP address (from the IP header) so that the inventive, non-proxy agent can mark the end of a particular connection. In response to the FIN TCP message, the server will respond with an ACK TCP message. In this case, the inventive, non-proxy agent will forward the frame to the client, but will terminate its tracking of the TCP connection from the client to the server. Similar messages will terminate the TCP connection from the server to the client.
[0057] Note that, in accordance with one embodiment of the present invention, all TCP connection establishment and termination messages are sent through the inventive, non-proxy agent, and that the TCP connection has been set up directly between the client and the server. However, in order to implement the functions that are described in detail below, the inventive, non-proxy agent maintains a subset of the TCP connection information to define an internal "TCP Connection State." An embodiment of a TCP Connection State and the manner of its use in accordance with an embodiment of the present invention will be described in detail below.
[0058] There are many methods that are well known to those of ordinary skill in the art for recognizing the various well known TCP connection establishment and termination messages so that they can be processed in the manner set forth above.
SSL Handshake
[0059] In accordance with this embodiment of the present invention, if a frame relates to the SSL handshake protocol, the inventive, non-proxy agent will respond to all such messages itself, and not pass such messages through to the server. As is well known to those of ordinary skill in the art, SSL comprises four (4) different component protocols: (a) change cipher; (b) alert; (c) handshake; and (d) application data. The main operations of SSL are: (a) to establish a secure session (this is accomplished by the handshake and change cipher protocols); (b) to transfer encrypted data (this is accomplished by the application data protocol); and (c) to handle errors (this is accomplished by the alert protocol). See a book by Stephen Thomas entitled "SSL and TLS Essentials, Securing the Web," published by John Wiley & Sons, Inc., 2000.
[0060] The handshake protocol comprises a series of phases that are well known to those of ordinary skill in the art, but for purposes of understanding embodiments of the present invention, it can be typically broken down into four (4) phases: (phase 1) a "client hello" message; (phase 2) a "server hello" message, "a server certificate" message and a "server hello done" message; (phase 3) a "client key exchange" message, a "change cipher spec" message, and a "finished" message; and (phase 4) a "change cipher spec" message and a "finished" message. In phase 1, the client sends some random numbers and a set of ciphers it can handle. In phase 2, the server decides on a particular cipher, and sends the client some random numbers and a certificate that contains the server's public key. In phase 3, the client verifies the server's authenticity and sends back some encrypted information to set the keys, and some encrypted authentication information about the whole session. After this, the client sends all subsequent messages encrypted according to the agreed-upon cipher parameters. Lastly, in phase 4, the server decrypts the information sent by the client and authenticates the session. The server sends back to the client some encrypted information to authenticate the session, and from this point on, all subsequent messages are encrypted according to the agreed-upon cipher parameters. The most time consuming component of this exchange for the server is the decryption of messages sent by the client since it is encrypted with the server's public key. For example, for RSA this involves thousands of arithmetic operations on very wide numbers. In addition to encryption, SSL enables an option of including message signatures (for SSL versions 3.0 and 3.1, message signatures are always included). Operations on the alternative signing algorithms have similar data dependencies as encryption, i.e., the packets have to be in order.
[0061] As is well known to those of ordinary skill in the art, SSL supports algorithms for a message authentication code ("MAC"). To calculate (or verify) the MAC, a system uses a two-stage hash very similar to hash computations in the handshake messages. It starts with a special value known as the MAC secret, followed by padding, a 64-bit sequence number, a 16-bit value with the length of the content, and, finally, by the content itself. For the second stage, the system uses the MAC write secret, padding, and the output of the intermediate hash. This result is the MAC value that appears in SSL messages. Two special values included in this calculation are the MAC write secret and the sequence number. The sequence number is a count of the number of messages the parties have exchanged. Its value is set to 0 with each ChangeCipherSpec message, and it is incremented once for each subsequent SSL Record Layer message in the session.
[0062] The SSL specification also recognizes that some of the information (in particular, the key material) will be different for each direction of communication. In other words, one set of keys will secure data the client sends to the server, and a different set of keys will secure data the server sends to the client. For any given system, whether it is a client or a server, SSL defines a write state and a read state. The write state defines the security information for data the system sends, and the read state defines the security information for data that the system receives. Thus, each state has a encryption algorithm, a write state encryption key, a read state encryption key, a message integrity algorithm (abbreviated "MAC" for Message Authentication Code) such as, for example and without limitation, Secure Hash Algorithm ("SHA") or RSA's Message Digest 5 ("MD5"), a write state MAC key, and a read state MAC key.
[0063] Whenever a new client tries to connect to a secure server, the client and server must execute the SSL Handshake protocol to agree on a cipher suite and session keys to be used for the secure data transfer as well as to authenticate each other. For a server, this handshake typically involves two reads and two writes. In accordance with this embodiment of the present invention, all of the above is performed by the inventive, non-proxy agent instead of the server. During the SSL handshake, among other things, the inventive, non-proxy agent saves SSL information to define an "SSL Connection State." An embodiment of an SSL Connection State and the manner of its use in accordance with an embodiment of the present invention will be described in detail below.
[0064] As is well known to those of ordinary skill in the art, SSL supports stream ciphers and block ciphers. As is also well known, block ciphers are typically sixty-four (64) bits wide (this is the case for DES and 3DES, which are the only block ciphers used in SSL versions 3.0 and 3.1), and are used in a cipher block chaining ("CBC") mode. In particular, this means that encoding/decoding a block of data (for example, each cipher specifies a standard block size) requires use of encoding/decoding results from immediately previous block(s). Although a stream cipher does not have such a dependency on the operation for a previous block, there is a dependency on the key. This requires that the inventive, non-proxy agent save this type of information as part of its "SSL Connection State." As is well known to those of ordinary skill in the art, block ciphers usually require an initialization vector of dummy data with which to begin the encryption process, i.e., the initialization vector primes the algorithm, and is determined as part of the SSL handshake in a manner that is well known to those of ordinary skill in the art.
[0065] There are many methods that are well known to those of ordinary skill in the art for recognizing the various well known SSL session messages so that they can be processed in the manner set forth above.
[0066] The following describes one embodiment of SSL handshake processing for the openssl implementation of SSL Version 3.0 handshake. In a first "server_read" step, the agent receives a client_hello message from the client that lists a set of proposed cipher suites to be used during the session and a 32 Byte random number that will be referred to below as the client random. In a first "server_write" step, the agent sends a server_hello message selecting one of the proposed cipher suites and a 32
Byte random number that will be referred to below as the server random. In a second "server_write" step (optional), the agent sends a server certificate message authenticating itself. In a third "server_write" step, the agent sends a message containing its signed public key (the client will use this to encrypt its session key); the public key is hashed and then signed using the agent's digital signature. This message is not required if the server_certificate has its RSA public key for encryption (a common case). This message is required only if the following conditions are true: (a) Diffie Hellman or Fortezza is used for key-exchange; (b) the server certificate is signed using DSS; (c) RSA is used for key exchange, but the server certificate does not have the RSA public key; (d) the agent is exporting the key exchange keys, and the keys specified in the server certificate enable strong RSA encryption; and (e) agent authentication is not required. In a fourth "server_write" step (optional), the agent sends a message requesting the client to authenticate itself. In a fifth "server_write" step, the agent sends a server_done message indicating that it is done.
[0067] In a first "server_read" step, the agent receives the client certificate, if requested and verifies it. In a second "server_read" step, the agent receives the client session key encrypted with the agent's public key. The agent decrypts the key and computes the master secret and the key material. In a third "server_read" step, the agent receives the finished message encrypted with the session key. The agent decrypts the messages and verifies that it is a hash of all the messages sent and received thusfar.
[0068] In a first "server_write step", the agent sends a change_cipher_spec message indicating that any message afterwards will be encrypted using the agreed upon session key. In a second "server write" step, the agent sends a finished message with a hash of all messages received thusfar, encrypted with the session key and authenticated.
TCP Packet Handling
[0069] In accordance with this embodiment of the present invention, to properly enable a TCP connection between a client and a server when traffic passes through the inventive, non-proxy agent, the inventive, non-proxy agent must modify TCP sequence numbers, in both directions. This must occur since, as was described above, the inventive, non-proxy agent, among other things, intercepts SSL handshake messages (and does not pass them through to the server), and decrypts/encrypts data in SSL session messages, thereby changing the amount of data contained in TCP packets. To understand how this occurs, assume, for the sake of illustration, that "A" is a sender ("A" could be a client or a server), and further assume, for the sake of illustration, that "B" is a recipient. In accordance with normal TCP handling, "B" will send an ack every now and then according to the rules of its TCP/IP protocol, which ack specifies the next byte of the TCP message "B" is ready to receive. As was discussed above, depending on the size of a TCP window, "A" may send multiple packets without having received any acks. As is well known to those of ordinary skill in the art, this is done to enable data to be transmitted on a steady basis. However, if at some point in the future when a timer at "A" expires since "A" has not received an ack, "A" will resend a packet whose payload starts from the byte in the TCP message corresponding to the last ack "A" received.
[0070] Further assume that the inventive, non-proxy agent is situated in the middle of the transmission between the client and the server. As each packet in the TCP connection goes by, the inventive, non-proxy agent adds/subtracts some number of bytes; due to padding, this number is not a constant. Whenever an ack goes back to the sender from the recipient, the inventive, non-proxy agent has to determine an appropriate offset for the ack in the TCP message so that the sender will send data starting from the appropriate position in the message. To further understand this, assume that the inventive, non-proxy agent received a packet from the sender that contained data corresponding to bytes 15 to 51 in the message (seq would equal 15 and the message length would equal 37 bytes), and that the inventive, non-proxy agent only sent bytes 15 to 41 from the message to the receiver as bytes 7 to 33 (for example, because inventive, non-proxy agent threw away 10 bytes). In such a case, the inventive, non-proxy agent would change the message length to 27. In response, the recipient would sent an ack which equals 34, i.e., the next byte it expected to receive. However, the sender has already sent byte 51. As a result, the inventive, non-proxy agent needs to adjust the ack to equal 52.
[0071] In addition, as described above, in order to enable an SSL session, the inventive, non-proxy agent must be mindful of the order of TCP packets, since encryption requires an ordered stream (for example, as described above, this is required by the CBC mode). The manner in which this is handled will be described in detail below.
Routing
[0072] In accordance with this embodiment of the present invention, if a frame relates to application data that is to be encrypted/decrypted according to parameters established during the SSL handshake, and then forwarded to the server/client, respectively, the inventive, non-proxy agent will perform the appropriate encryption/decryption, and forward the resulting information. As one can readily appreciate, traffic that the inventive, non-proxy agent decrypted on the way from the client to the server must be encrypted using the same cipher suite on the way from the server to the client. In essence, this means that both traffic directions must go through the inventive, non-proxy agent. This can occur in accordance with any one of a number of methods. For example, in one configuration, an embodiment of the inventive, non-proxy agent is placed in front of a load balancer (a load balancer is an apparatus that is well known to those of ordinary skill in the art) which is, itself, in front of a server to which secure transactions are to be directed. As another example, the inventive, non-proxy agent spoofs the Internet frame address which appears in the frame header in a manner that is well known to those of ordinary skill in the art to indicate the source of a frame to be the inventive, non-proxy agent.
Non-Proxy Agent
[0073] The following describes one embodiment of the present invention which is an inventive, non-proxy agent.
[0074] FIG. 4 shows a block diagram of an embodiment of an inventive, non-proxy, SSL system. As shown in FIG. 4, network interfaces 1001 and 1003 of inventive, non-proxy, SSL system 1000 connect to client and server networks, respectively. Many methods are well known to those of ordinary skill in the art for fabricating network interfaces 1001 and 1003. In accordance with this embodiment of the present invention, traffic flows bi-directionally between a multiplicity of clients and servers, but for clarity and ease of understanding this embodiment of the present invention, inbound packet direction for a connection between a single client and server is shown only. As shown in FIG. 4, link layer (layer 2) traffic comes over a network, for example and without limitation, a public network such as the Internet, into network interface 1001, and is passed to unit 1002. As should readily be appreciated by those of ordinary skill in the art, network interfaces 1001 and 1003
handle layers 1 and 2 of a network protocol. In accordance with this embodiment of the present invention, unit 1002 is embodied as a hardware logic unit that itself is implemented in a field-programmable gate array ("FPGA"), although other implementations are possible including, for example and without limitation, a standard network processor unit (NPU), a central processing unit (CPU), an application-specific integrated circuit ("ASIC"), and so forth.
[0075] In accordance with this embodiment of the present invention, unit 1002 performs a pre-filter function. In particular, it tags an incoming frame with, for example, physical identifiers such as, input port number (used to route traffic), and checks the incoming frame: (a) to determine whether the checksum is proper or whether the frame is incomplete (if the checksum is improper, or the frame is incomplete, the input is dropped); and (b) to determine whether the frame is a non-IP or a non-SSL frame (if it is a non-IP or non-SSL frame, it is sent to a network interface for forwarding to the receiver). If the incoming frame passes the pre-filter function performed by unit 1002, data contained therein is forwarded to unit 1004 for further filtering. This data comprises the TCP segment and will be referred to as a TCP packet.
[0076] In accordance with this embodiment of the present invention, unit 1004 determines whether the TCP packet corresponds to Bulk data transfer (i.e., data transfer between the client and server after the TCP connection and the SSL session have been established). If unit 1004
determines that a TCP packet relates to Bulk data transfer for an existing TCP connection and an existing SSL session, the TCP packet is sent to bulk encryption/decryption unit 1006 for processing. If not, because, for example, the TCP packet relates to TCP connection establishment (between the client and server), TCP connection termination (for either the client or the server), SSL handshake (between the client and inventive, non-proxy, SSL system 1000), or SSL session termination, it is sent to CPU 1005 for processing. In accordance with this embodiment of the present invention, unit 1004 is embodied as a hardware logic unit that itself is implemented in an FPGA, although other implementations are possible including, for example, and without limitation, a standard network processor unit (NPU), a central processing unit (CPU), or an application-specific integrated circuit (ASIC).
[0077] Unit 1004 makes the above-described determination, for example, by referring to the existence of an entry in a connection table, implemented in one embodiment as a "Client Hash Table" for an established TCP connection and an established SSL session which relates to the TCP packet. In accordance with one embodiment of the present invention, the Client Hash Table is stored (storage may be any one of a number of storage devices that are well known to those of ordinary skill in the art such as a memory device) in storage having shared access by unit 1004, unit 1006, and CPU 1005, which Client Hash Table is created in a manner that will be described in detail below. In accordance with one embodiment of the present invention, a retrieval key for the Client Hash Table is a combination of the client IP address (from the IP header) and client TCP port number (from the TCP header). In accordance with this embodiment of the present invention, the entry in the Client Hash Table is made by CPU 1005 after the SSL handshake has been completed, and the entry comprises a pointer to an entry in a "Buff TCP Control Block." The Buff TCP Control Block comprises a TCP Connection State (see Table I which shows one embodiment of a TCP Connection State) and an SSL Connection State (see Table II which shows one embodiment of an SSL Connection State), which entry in the Buff TCP Control Block is also made by CPU 1005 after the SSL handshake has been completed. The Buff TCP Control Block is stored in a storage device having shared access by unit 1006 and CPU 1005 (the storage device may be any one of a number of types of storage devices that are well known to those of ordinary skill in the art such as a memory device).
[0078] CPU 1005 is a standard CPU running software that can handle TCP connection establishment, TCP connection termination, SSL handshake, SSL session termination, and bulk data exchange. In one embodiment of the present invention, CPU 1005 only handles "corner cases" for bulk data exchange.
TCP Connection State
[0079] In accordance with one embodiment of the present invention, CPU 1005 processes TCP packets to handle TCP connection establishment and termination. Each TCP segment contains a 16-bit source port number and a 16-bit destination port number to identify the sending and receiving applications, and as is well known to those of ordinary skill in the art, these two values, along with a 32-bit source IP address and a 32-bit destination IP address in the IP header, uniquely identify each TCP connection.
[0080] In accordance with one embodiment of the present invention, whenever a client sends a secure message to a server, it accesses a predetermined destination port number (for example and without limitation, 443, or some other predetermined number). In this embodiment of the present invention, this fact may be used to identify SSL messages. However, since SSL system 1000 decrypts messages intended for the server, it changes the destination port number whenever the decrypted counterparts are forwarded to the server to a destination port number that has not been earmarked to receive encrypted messages (for example and without limitation, 8080, or some other predetermined number). Likewise, whenever the server sends messages to the client, it does not send them to a port that has been earmarked to receive encrypted messages because the server transmits its messages in plaintext to SSL system 1000. In one specific embodiment, the server sends its messages to port 8080. However, since SSL system 1000 encrypts messages intended for the client, it changes the destination port number whenever the encrypted counterparts are forwarded to the client to a port number that is earmarked to receive encrypted messages (for example and without limitation, 443, or some other predetermined number). As a result, for such an embodiment, the TCP connection is identified by the 32-bit source IP address, and the 16-bit source port number.
[0081] In accordance with one embodiment of the present invention, CPU 1005 places an entry into a "Client Hash Table" in a storage device having shared access with unit 1004 and unit 1006 (the storage device may be any one of a number of types of storage devices that are well known to those of ordinary skill in the art such as a memory device). Each entry is reached by processing a retrieval algorithm using the 32-bit source IP address and the 16-bit source port number of the TCP connection as a retrieval key. In accordance with one embodiment of the present invention, this algorithm is a hash algorithm. The entry in the Client Hash Table is a pointer to a Buff TCP Control Block that includes a TCP Connection State and an SSL Connection State. The Client Hash Table is set up by CPU 1005 after the TCP connection has been established, and after the SSL session has been established. The Buff TCP Control Block is initially created by CPU 1005, and is stored in a storage device having shared access with unit 1006 (the storage device may be any one of a number of types of storage devices that are well known to those of ordinary skill in the art such as a memory device) for use in processing bulk data in the manner described in detail below.
[0082] Table I shows information stored in a TCP Connection State for one embodiment of the present invention. As was discussed above, in accordance with this embodiment of the present invention, SSL system 1000
is a non-proxy agent and, as a result, there is no need to store all of the information associated with a TCP connection. Thus, for each TCP connection, several variables are saved for each direction of information flow, along with a pointer to an associated SSL Connection State; the variables will be described in detail below.
[0083] After the TCP Connection State and the SSL Connection State have been set up (see below), and an entry has been created in the Client Hash Table, TCP packets are filtered in unit 1004. Unit 1004 does this by searching the Client Hash Table for an entry corresponding to the client IP address and the client port to determine whether a TCP connection and an SSL session have been established for the TCP packet. If so, the TCP packet is sent to bulk encryption/decryption unit 1006 directly for processing--with no interaction by CPU 1005. Advantageously, this enhances the performance of SSL system 1000, because the data rate of TCP packets entering SSL system 1000 is typically far greater than the capacity of CPU 1005 to handle each TCP packet.
SSL Connection State
[0084] In accordance with this embodiment of the present invention, an SSL session is established for every client that requests a secure service through an SSL handshake. In accordance with this embodiment of the present invention, and for ease of understanding the present invention, SSL system 1000 maintains an SSL Connection State that is independent of the TCP Connection State.
[0085] As was described above, and as is well known to those of ordinary skill in the art, a typical SSL session includes: (a) an SSL handshake (all of whose messages are described in detail in a book entitled "SSL and TLS Essentials, Securing the Web" by Steven Thomas, Published by John Wiley & Sons, Inc., 2000) to establish the SSL session; (b) then, a sequence of TCP packets of application data, and (c) then, an SSL Finish and possibly other messages to end the session. In accordance with this embodiment of the present invention, CPU 1005 handles the SSL handshake and session termination, and then turns over the rest of the task of handling the SSL session bulk data transfer to unit 1006.
[0086] In accordance with one embodiment of the present invention, SSL system 1000 precludes the server from receiving data that has a bad signature. To do this, whenever CPU 1005 detects a bad signature during SSL handshake, it sends an SSL alert message to the client to cause the client to close the connection. The closure will not be seen by the server, and the transaction will fail.
[0087] CPU 1005 creates an SSL Connection State and stores it in Buff TCP Control Block, storing a pointer to the SSL Connection State in the associated TCP Connection State. The SSL Connection State is stored in a storage device that is shared with unit 1006 (the storage device may be any one of a number of types of storage devices that are well known to those of ordinary skill in the art such as a memory device). Further, whenever, the SSL handshake is complete, the SSL Connection State is associated with the TCP Connection State, and an entry is made in the Client Hash Table with a pointer to the TCP Connection State.
[0088] An example of an SSL Connection State for one embodiment of the present invention is shown in Table II, some of the entries in SSL Connection State for this embodiment of the present invention include: (a) Cipher Code; (b) read state Cipher Key; (c) write state cipher key; (d) hash algorithm code (MAC); (e) read state MAC secret; and (e) write state MAC secret. The remaining entries will be described in detail below.
[0089] In accordance with this embodiment of the present invention, whenever an SSL alert, or any other SSL protocol-level message, is detected in a TCP packet by unit 1004 filtering, the TCP packet is sent to CPU 1005 for processing.
[0090] CPU 1005 will end an SSL session if it detects TCP connection termination messages following an SSL alert message.
Bulk Data
[0091] In accordance with one embodiment of the present invention, unit 1006 performs encryption/decryption on application data for an SSL session. In accordance with this embodiment of the present invention, unit 1006 is embodied as a hardware logic unit that itself is implemented in an FPGA, although other implementations are possible including, for example, and without limitation, a standard network processor unit (NPU), a central processing unit (CPU), or an application-specific integrated circuit (ASIC).
[0092] In accordance with this embodiment of the present invention, unit 1006 accesses the SSL Connection State and the TCP Connection State to obtain information needed to perform the encryption/decryption function, and to obtain information needed to modify the TCP state seq and ack numbers in the manner described above. After that, the decrypted/encrypted and modified TCP packet is incorporated into a frame, and the frame is forwarded to the appropriate one of the server/client, respectively.
[0093] SSL system 1000 must order TCP packets, since, as was described above, encryption/decryption requires an ordered stream (for example, this is required by the CBC mode). Thus, if SSL system 1000 receives TCP packets out of order, they cannot be forwarded. There are at least two options for handling this situation. A first option is to drop out-of-order packets, and wait for them to be resent in order. This first option is advantageous since it reduces buffering. In time, the receiver's TCP layer routines will request a resend since, as far as they are concerned, the out-of-order packets will appear to have been dropped. A second option is to buffer the TCP packets, and to wait for a TCP packet that should have been sent previously to be resent. This second option requires buffering, and as a result, is more complex than the first option. In accordance with one embodiment of the present invention, the first option is implemented in unit 1006.
[0094] As is well known to those of ordinary skill in the art, a TCP packet can contain any number of SSL messages, or it may contain a piece of an SSL message. As was described above, TCP packets are sent to unit 1006 for processing. In accordance with this embodiment of the present invention, whenever a TCP packet contains one SSL message, the bulk application data processing is handled by unit 1006. On the other hand, whenever unit 1006 determines that an inbound TCP packet contains a portion of an SSL message (in practice, this determination is made for the first inbound TCP packet of the SSL message), or more than one SSL message, unit 1006 will forward the inbound TCP packet to CPU 1005 for bulk application data processing. In addition, unit 1006 will set a "punt" bit in the Client Hash Table. Whenever unit 1006 processes an inbound TCP packet, it will check the Client Hash Table for the particular connection, and examine its "punt" bit. If the "punt" bit is set, unit 1006 will forward the inbound TCP packet to CPU 1005 for processing. In this manner, in one such embodiment, CPU 1005 can gather multiple inbound TCP packets together in order to provide one SSL message. After CPU 1005 has received the entire SSL message, processed it, and forwarded it to the server, it will clear the "punt" bit so that unit 1005 may resume normal operation. In another such embodiment, CPU 1005 groups the information in the inbound TCP packets in order and groups the information into blocks. Then, CPU 1005 can process the information, on a block by block basis, to generate TCP packets that it will send to the server to speed up transmission. In this case, whenever the last TCP packet relating to the SSL message arrives, it will contain the signature (if one is used for the particular version of SSL). If the signature is bad, CPU 1005 can cause the session to be dropped in the manner described herein.
[0095] In accordance with this embodiment of the present invention, in general, whenever any condition causes unit 1006 to send a TCP packet to CPU 1005 for processing (see above), unit 1006 will send all subsequent traffic coming from the same sender to CPU 1005 for processing to make sure, for example, that TCP packets forming an SSL message are processed in order. If this were not done, processing of subsequent TCP packets by unit 1006, might get out of order since unit 1006 (if embodied in logic) might operate faster than CPU 1005. Normal processing of TCP packets from the particular sender by unit 1006 can resume whenever CPU 1005 catches up with the sender (this is guaranteed to occur because of the TCP window size functionality which will inhibit the sending of TCP packets if the sender's window has been filled by unacknowledged packets). To effectuate this coordination, as was described above, whenever unit 1006 forwards a TCP packet to CPU 1005, it will set the "punt" bit in the Client Hash Table. Further, whenever a TCP packet arrives, and unit 1006 accesses the Client Hash Table for a pointer to the TCP Connection State for the associated connection and finds the "punt" bit set in the Client Hash Table, it will forward the TCP packet to CPU 1005 for processing. In addition, whenever CPU 1005 catches up, it will reset the punt bit so that unit 1006 will resume processing TCP packets from the particular sender.
[0096] In a case where one outbound plaintext message spans multiple TCP packets, since outbound TCP packets are plain text, instead of waiting to form one SSL message (as would occur in a prior art, proxy mode agent with SSL running on a TCP/IP stack of the server), unit 1006 can create a separate SSL message for each TCP packet (without waiting to receive the entire plaintext message). As a result, the client will receive more SSL headers and trailers than it would if there were one SSL message. Nevertheless, the client will still assemble the TCP packets into a single SSL message. Thus, the application (for example, a web browser) receives the exact same data it would have received if the TCP packets were collected to enable a single SSL message to be formed (this is because the SSL code in the client strips off the headers/trailers, and passes the payload up to the application layer). Consequently, instead of receiving 16 Kbytes of data wrapped in one SSL message, the client receives ten (10) 1.5 Kbyte TCP packets each wrapped in an SSL message. Advantageously, such an embodiment of the present invention eliminates the need to buffer the whole message (to be able to calculate an SSL length, the SSL length is in the SSL header) before sending the first TCP packet. Note that this approach of sending through TCP packets as they arrive and not waiting to obtain an entire SSL message may also be used in a proxy-mode agent.
[0097] As is well known to those of ordinary skill in the art, processing TCP packets (for example, encryption) in the outbound direction increases the size of the TCP packets. As a result, this could produce fragmentation, or multiple segments. Multiple segments are problematic because they may end up complicating the non-proxy behavior of SSL system 1000.
[0098] As set forth in the following quote from page 233 of the book entitled "TCP/IP Illustrated, Volume 1-The Protocols" by W. Richard Stevens, published by Addison-Wesley, 1994:
[0099] The maximum segment size (MSS) is the largest "chunk" of data that TCP will send to the other end. When a connection is established, each end can announce its MSS. The values we've seen have all been 1024. The resulting IP datagram is normally 40 bytes larger: 20 bytes for the TCP header and 20 bytes for the IP header.
[0100] Some texts refer to this as a "negotiated" option. It is not negotiated in any way. When a connection is established, each end has the option of announcing the MSS it expects to receive. (An MSS option can only appear in a SYN segment.) If one end does not receive an MS option from the other end, a default of 536 bytes is assumed. (This default allows for a 20-byte IP header and a 20 byte TCP header to fit into a 576
byte IP datagram.)
[0101] In general, the larger the MSS the better, until fragmentation occurs. (This may not always be true. . . . ) A larger segment size allows more data to be sent in each segment, amortizing the cost of the IP and TCP headers. When TCP sends a SYN segment, either because a local application wants to initiate a connection, or when a connection request is received from another host, it can send an MSS value up to the outgoing interface's MTU, minus the size of the fixed TCP and IP headers. For an Ethernet this implies an MSS of up to 1460 bytes. Using IEEE 802.3
encapsulation (Section 2.2), the MSS could go up to 1452 bytes.
[0102] One solution is to adjust the MSS advertised by the client by subtracting, for example and without limitation, thirty-three (33) bytes from it in accordance with the method disclosed in patent application entitled "Optimizing Layer I/ Layer J Connections in a Network Having Intermediary Agents, Ser. No. 09/560,951 Filed Apr. 27, 2000, which application is commonly assigned with the present application and which application is incorporated herein by reference. For example, in accordance with this method, this number is the size of an SSL header (5), plus the maximum signature size (20), plus an allowance for padding (8). In accordance with this embodiment of the present invention, adjusting MSS is performed at TCP connection establishment, and is performed by CPU 1005.
SSL system Flowchart
[0103] FIG. 7 shows a flowchart of operation of SSL system 1000 shown in FIG. 4. As shown in FIG. 7, messages are received by, and sent from, SSL system 1000 using a network interface. A message received by a network interface at box 4000 of FIG. 7, is passed to box 4010 of FIG. 7 for pre-filtering. At box 4010, if an error in the frame is detected, the TCP packet is dropped; if the frame is a non-SSL frame, control is transferred to box 4000 so a network interface can send the TCP packet onto the network to the appropriate destination; otherwise, control is transferred to box 4020 of FIG. 7. At box 4020, the Client Hash Table is accessed to determine whether a TCP connection and an SSL session have been set up for this TCP packet. If so, control is transferred to box 4030 of FIG. 7, otherwise, control is transferred to box 4025 of FIG. 7
for further analysis (the operation of box 4025 is described below in conjunction with FIG. 8).
[0104] At box 4030, the SSL header and the TCP sequence number of the TCP packet are examined. If the TCP packet contains an SSL alert message, or an unusual message, or a TCP connection termination message, control is transferred to box 4025 of FIG. 7, otherwise, control is transferred to box 4040 of FIG. 7. At box 4040, the TCP Connection State and the SSL Connection State are retrieved (in a manner described in detail herein), and control is transferred to box 4050 of FIG. 7. At box 4050, the bulk data encryption/decryption process is carried out. If a decryption error or a signature error is detected, control is transferred to box 4025 of FIG. 7, otherwise, control is transferred to box 4060 of FIG. 7. At box 4060: (a) the TCP Connection State and the SSL Connection State are updated (in a manner described in detail herein); (b) the seq number, the ack number, and the port number of the TCP packet are adjusted (in a manner described in detail herein); (c) the checksum for the TCP packet is recomputed; and (d) control is transferred to box 4000 so a network interface can send the TCP packet onto the network to the appropriate destination.
[0105] FIG. 8 shows a detailed flowchart of the operation of box 4025
shown in FIG. 7. As shown in FIG. 8, control is transferred to box 4100
whenever an entry does not exist in the Client Hash Table for a particular TCP packet. At box 4100, TCP connection establishment is processed and SSL handshake is performed (in a manner described in detail herein). After that, control is transferred to box 4110 of FIG. 8. At box 4110, a determination is made to see whether the TCP connection establishment and the SSL handshake were successful. If so, control is transferred to box 4130 of FIG. 8, otherwise, control is transferred to box 4120 of FIG. 8. At box 4120, an SSL alert message is sent to the client, followed by TCP connection termination messages. At box 4130, a TCP Connection State and an SSL Connection State are created, and an entry is made in the Client Hash Table.
[0106] As further shown in FIG. 8, control is transferred to box 4150
whenever an SSL alert message, or an unusual message, or a TCP connection termination message is received. At box 4150, the SSL alert message is processed, large SSL messages are processed, or session termination messages are processed.
[0107] As still further shown in FIG. 8, control is transferred to box 4170 whenever there is a decryption error or a signature error. At box 4170, TCP reset messages are sent to the server, and an SSL alert message is sent to the client.
Physical Implementation
[0108] In accordance with one embodiment of the present invention, SSL system I1000 is implemented as a blade/card that can plug into a host system, can process from about 2000 (SSL messages)/sec to about 5000 (SSL messages)/sec, and can decrypt messages at line speed. In addition, blades/cards can be combined in a four blade/card system that can process from about 8000 (SSL messages)/sec to about 20000 (SSL messages)/sec. In accordance with the present invention, use of inventive, SSL system 1000
relieves a server of all SSL processing so that it can simply service plain HTTP requests. Advantageously, inventive, SSL system 1000 can be placed as a "bump in the wire" somewhere in front of the server, most likely in front of an Internet traffic manager (ITM), also known in the art as a load balancer. This configuration has at least three important benefits. The first benefit is that it can service SSL traffic for several servers, with no need to modify either the server's hardware configuration, or to change the server's software in a significant way. The second benefit arises from the fact that the ITM will see traffic in the clear. As a result, the ITM can make more intelligent decisions to provide overall improvement to the site. The third benefit arises from the fact that the inventive, SSL system is not a proxy agent (i.e., it does not establish connections; it merely modifies existing connections), so that TCP traffic is modified on the flight. This reduces buffering requirements, and enables the most time consuming aspects of SSL, namely SSL handshake and bulk encryption, to be accelerated, for example, in hardware.
Bulk Application State Machine
[0109] Overview
[0110] FIG. 5 shows a general case wherein: (a) client 2000 sends a packet with TCP sequence number seq to SSL system 1000; (b) SSL system 1000
decrypts the data and (for the reasons described in detail above) changes the TCP sequence number from seq to seq'; and (c) SSL system 1000 sends the altered TCP packet to server 2010. In addition, as shown in FIG. 5, (a) server 2010 sends a packet with TCP acknowledgment number ack' to SSL system 1000; (b) SSL system 1000 encrypts the data and (for the reasons described in detail above) changes the TCP acknowledgment number from ack' to ack; and (c) SSL system 1000 sends the altered TCP packet to client 2000.
[0111] As one can readily appreciate from this, SSL system 1000 does not control correspondence between TCP packets sent and acknowledgments received. As a result, in accordance with one embodiment of the present invention, SSL system 1000 stores an ack offset (i.e., the difference between the acknowledgment number, ack', in the TCP packet sent from the receiver, for example, the server, and the acknowledgment number, ack, corresponding to ack' that SSL system 1000 will send to the sender, for example, the client) for each TCP packet it has forwarded to the receiver, for example, the server. As one of ordinary skill in the art can readily appreciate, SSL system 1000 would need to store this ack offset to enable it to modify any ack' that it may receive from the receiver, for example, the server. In such an embodiment, whenever SSL system 1000 receives an ack' from, for example, server 2010, SSL system 1000 takes this as an indication to free up memory of all stored offsets before that point, i.e., prior to ack'. There would be an exception to this however, i.e., whenever the TCP ack packet SSL system 1000 sends back to client 2000 gets dropped. Methods for dealing with this situation are described below.
[0112] In an alternative of this embodiment, the number of outstanding TCP packets (i.e., TCP packets that have been sent from SSL system 1000 to, for example, the server, but for which no acknowledgment has been received by SSL system 1000) can be limited. In practice, as has been described above, the limit is a function of the number of TCP packets that can fit into a TCP window. Thus, whenever the TCP window is filled, no data gets sent, and SSL system 1000 will have an opportunity to catch up. Although SSL system 1000 can have control over the size of the TCP window (for example, by spoofing the window size option), there still may be many small TCP packets that go through SSL system 1000 which require storage of many ack offsets. In such a case, in accordance with such an embodiment, once a TCP ack offset table overflows its n entries (for example and without limitation, n=16), SSL system 1000 could compensate by dropping TCP packets.
[0113] The following describes further embodiments of the present invention that are driven by the fact that, in accordance with the TCP protocol, a previously sent TCP packet may be resent. For example, whenever a TCP packet is dropped (for example, the TCP packet is lost between SSL system 1000 and the client or between SSL system 1000 and the server), in accordance with the TCP protocol, that event will be detected eventually (for example and without limitation, because timers expire in a manner that is well known to those of ordinary skill in the art). Then, in accordance with the TCP protocol, a previously sent TCP packet will be resent (this action being referred to herein as a "rewind"). To properly deal with such "rewinds" that occur as a natural consequence of the TCP protocol, these further embodiments need to be able to "rewind" the TCP sequence numbers (i.e., the seq and its corresponding seq' or the ack and its corresponding ack'), and they need to be able to "rewind" the encryption/decryption of the messages as well. As one can readily appreciate from the above, there is a need to "rewind" the TCP sequence numbers to have the proper translation of a received seq to seq' or the proper translation of a received ack' to ack, respectively. In addition, as one can readily appreciate from the above, there is a need to "rewind" the encryption/decryption of the messages to be able the encrypt/decrypt the resent TCP packet.
Inventive "Rewind Methods"
[0114] One issue in implementing the "rewind" function that must be kept in mind is that SSL generates a relatively large encryption state for a stream cipher such as, for example, the RC4 variable-key size stream cipher. For example, for RC4, the encryption state comprises a 256-byte encryption state plus two (2) additional bytes for other information that is well known to those of ordinary skill in the art, see a book entitled "Applied Cryptography, Second Edition, Protocols, Algorithms, and Source Code in C" by Bruce Schneier, John Wiley & Sons, 1996, Chapter 17, pp. 397-98.
[0115] As is well known to those of ordinary skill in the art, for a stream cipher, the keystream is independent of the plaintext. Thus, for a stream cipher such as RC4, given the RC4 state of a particular byte in a message, one can compute the RC4 state (and the key) for any other byte in the message given just its position with respect to the particular byte. In other words, if one knows the RC4 state of a byte B1 in a sequence of encrypted (or decrypted) messages, then the RC4 state (and the key) can be computed for any other byte B2 in the message, given the position of byte B2 relative to the position of byte B1 in the message, i.e., (position(B2)-position(B1). Of course, one would have to subtract all bytes in the message that are not encrypted such as, for example, bytes in SSL headers from (position(B2)-position(B1). The important thing to note, therefore, is that the computation of the RC4 state (and the key) is independent of the message itself.
[0116] This is illustrated as follows. First, to initialize the RC4 state: (a) initialize an S-box by filling it linearly S.sub.0=0, S.sub.1=1, . . . , S.sub.255=255; (b) set two bytes Si and Sj to 0; and (c) fill a 256-byte array with the key, repeating the key as necessary to fill the entire array K.sub.0, K.sub.1, . . . K.sub.255. The key is five (5) bytes for export or as much as 16 bytes for other uses. Then perform the following:
[0117] j=0
[0118] for i=0 to 255;
[0119] j=(j+S.sub.i+K.sub.i) mod 256
[0120] Swap S.sub.i and S.sub.j.
[0121] Then, to generate a random byte, perform the following:
[0122] Si=(Si+1) mod 256
[0123] Sj=(Sj+S.sub.Si) mod 256
[0124] swap S.sub.i and S.sub.j
[0125] t=(S.sub.i+S.sub.j) mod 256
[0126] K=S.sub.t
[0127] Then, the byte K is XORed with the plaintext to produce ciphertext or XORed with the ciphertext to produce plaintext.
[0128] A "saved state" is encryption/decryption state information (also referred to herein as a cipher state) that is necessary and sufficient to enable SSL processing (i.e., encryption/decryption) of a TCP packet. The "saved state" can be "rewound" using the RC4 rewind algorithm starting with a "saved state" to obtain the "saved state" of, for example, a retransmitted packet. The RC4 rewind algorithm is:
[0129] swap S.sub.Si and S.sub.Sj
[0130] Sj=(Sj-S.sub.Si+256) mod 256
[0131] Si=(Si-1+256) mod 256
[0132] For a block cipher such as, for example, the DES or 3DES block ciphers, since the encryption state is not independent of the message, one cannot "rewind" without the data (as was noted above, encoding/decoding a block of data requires use of encoding/decoding results from immediately previous block(s)). However, for the DES and 3DES block ciphers, the encryption state is only eight (8) bytes per block in each direction of transmission.
"Rewind Method I"
[0133] In accordance with one embodiment of the present invention, SSL system 1000 updates a decryption state as each TCP packet is processed (those of ordinary skill in the art will readily appreciate that the following applies as well to a direction of transmission requiring encryption). For example, using RC4, SSL system 1000 buffers (or stores) the 256-byte decryption state at all TCP packet boundaries, or, alternatively, it buffers (or stores) the actual decrypted data. These data are buffered (or stored) along with the seq and seq' correspondence data. To understand how "Rewind Method I" works, assume, for the sake of illustration, that: (a) four (4) TCP packets have been received by SSL system 1000 from, for example, client 2000; (b) SSL system 1000 has performed decryption, using, for example, RC4, on these TCP packets in succession; and (c) SSL system 1000 has, therefore, updated and buffered (or stored) the decryption state, for example, the 256-byte decryption state, (or alternatively, the decrypted data) for each. Assume further that TCP packet number 3 is dropped between SSL system 1000 and server 2010, and, as a result, that client 2000 resends TCP packet number 3
because client 2000 has not received an acknowledgment before a timer expires. In accordance with "Rewind Method I", SSL system 1000 "rewinds" i.e., decrypts, TCP packet number 3 by: (a) (where the 256-byte decryption state is buffered (or stored) at all TCP packet boundaries) decrypting the resent TCP packet from the decryption state; or (b) (where the actual decrypted data is buffered (or stored)) retrieving the actual decrypted data.
"Rewind Method II"
[0134] To handle dropped or lost TCP packets, and to retransmit those dropped or lost TCP packets, SSL system 1000 buffers (or stores) information described below; which information is buffered (or stored) in a TCP Connection State (see Table I which shows one embodiment of a TCP Connection State) and an SSL Connection State (see Table II which shows one embodiment of an SSL Connection State). As described above, the TCP Connection State and the SSL Connection State are stored in storage, for example, a storage unit such as memory, that is accessible to CPU 1005
and unit 1006 shown in FIG. 4. Further, as was described above, the Client Hash Table has a pointer which points to the TCP Connection State, and as shown in Table I, the TCP Connection State has a pointer to the SSL Connection State.
[0135] Variable InBackSeqPair represents a pair (InBackSeq, InBackSeq') of TCP sequence numbers for the next expected seq number after the last TCP packet for which an acknowledgment was sent from SSL system 1000 to the client (i.e., InBackSeq=seq [of the last TCP packet for which an acknowledgment was sent] plus its length). InBackSeq is the TCP sequence number of a TCP packet as it would be received by SSL system 1000 from the client, and InBackSeq' is the TCP sequence number of the TCP packet as it would be sent from SSL system 1000 to the server. The variable InBackSeqPair is also referred to as a "backup state."
[0136] A "saved state" is encryption/decryption state information (also referred to herein as a cipher state) that is necessary and sufficient to enable SSL processing (i.e., encryption/decryption) of a TCP packet. The "saved state" for the "backup state" is the "saved state" for a TCP packet whose first byte has a TCP sequence number equal to InBackSeq.
[0137] Variable InMaxSeqPair represents a pair (InMaxSeq, InMaxSeq') of TCP sequence numbers for the next expected seq number after the last TCP packet SSL system 1000 sent to the server (i.e., InMaxSeq seq [of the last TCP packet SSL system 1000 sent to the server] plus its length). InMaxSeq is the TCP sequence number of a TCP packet as it would be received by SSL system 1000 from the client, and InMaxSeq' is the seq number of the TCP packet as it would be sent from SSL system 1000 to the server. The variable InMaxSeqPair is also referred to as the "forward state." The "saved state" for the "forward state" is the "saved state" for a TCP packet whose first byte has a TCP sequence number equal to InMaxSeq.
[0138] Variable OutLastAck' is the largest outgoing ack number SSL system 1000 received from the server.
[0139] As one can readily appreciate, the above-described variables correspond to operations concerning transmission from a client to a server. Similar variables, having similar meaning, are shown in Table I, and correspond to transmission from the server to the client.
[0140] For this embodiment, the "saved states" for the "backup state" and the "forward state" for the incoming and outgoing directions of transmission are stored in the SSL Connection State (see Table II).
[0141] The following relations will always be true between the above-described variables for a given direction of transmission:
[0142] InBackSeq'.ltoreq.OutLastAck'.ltoreq.InMaxSeq'
[0143] InBackSeq.ltoreq.InMaxSeq
[0144] InBackSeq>InBackSeq' and InMaxSeq>InMaxSeq'
[0145] Based on these variables, a TCP Connection State can only be in one of the following states:
[0146] State 1: InBackSeq'=OutLastAck'=InMaxSeq'
[0147] This state, denoted CAU (caught up), occurs whenever SSL system 1000 has received an ack from the server for every TCP packet that S SL system 1000 has sent it thusfar. Thus, the server is caught up with the client. As a result, SSL system 1000 can update the "backup state" to refer to the TCP packet most recently sent to the server. Because SSL system 1000 knows the server has already received the last TCP packet SSL system 1000 sent, there is no situation in which SSL system 1000 will have to re-decrypt data earlier in the connection.
[0148] State 2: InBackSeq'=OutLastAck'<InMaxSeq'
[0149] This state, denoted NAC (No Ack), occurs whenever SSL system 1000
has not received any acks for any TCP packets it sent since it was in the CAU state (i.e., since receiving the last ack). This means that the server is backed up. If SSL system 1000 receives a retransmission from the client in this state, there is a good chance that a TCP packet and/or an ack got lost between SSL system 1000 and the server.
[0150] State 3: InBackSeq'<OutLastAck'<InMaxSeq'
[0151] This state, denoted by SAC (Some Ack), is a "steady state" and occurs whenever the server sent an ack for some of the TCP packets it received from SSL system 1000, but not all. On receiving a retransmission from the client while in this state, SSL system 1000 will advance the "backup state" until it reaches: (a) a CAU state (if no TCP packets are lost), or (b) a NAC state (if some TCP packets are lost or if the server is backed up).
[0152] State 4: InBackSeq'<OutLastAck'InMaxSeq'
[0153] In accordance with this embodiment of the present invention, as soon as a connection reaches this state, SSL system 1000 will set (InBackSeq, InBackSeq') to (InMaxSeq, InMaxSeq') to drive it to the CAU state. This means that the "backup state" becomes the last sent TCP packet.
[0154] As is well known to those of ordinary skill in the art, a typical SSL message includes a message, a signature, and padding. In order for the message to be decrypted for transmission from SSL system 1000 to the server, the entire SSL message must be decrypted using an appropriate encryption/decryption algorithm determined during SSL handshake (for example, see Table II) and an appropriate Cipher State to determine the padding length. Using the padding length, the signature and the message can be identified. Next, the signature can be authenticated using an appropriate authentication algorithm determined during SSL handshake and appropriate keys (for example, see Table II). Lastly, the authenticated message can be sent to the server as plaintext. Conversely, in order to encrypt a plaintext message for transmission from SSL system to the client, SSL system computes a signature using the appropriate authentication algorithm and the appropriate keys (for example, see Table II), pads the message and signature, adds a padding length, and encrypts the entire SSL message using the appropriate encryption/decryption algorithm and the appropriate Cipher State.
[0155] In accordance with one embodiment of the present invention, two kinds of inputs can change the state of a connection in SSL system 1000: (a) an outgoing ack in a TCP packet, or (b) an incoming TCP packet. Tables III and IV show state transitions generated by a state machine for inbound traffic (the state machine for outbound traffic is equivalent); which state transitions occur in response to each of these kinds of inputs separately. Many methods are well known to those of ordinary skill in the art for implementing such a state machine. In addition, in accordance with the further embodiment of the present invention, all state transitions due to acks will be handled in unit 1006.
[0156] The following provides some explanations to help in understanding the manner in which the state machine works.
Table III
[0157] Before describing each state transition in detail in conjunction with Table III, the following provides an overview.
[0158] Whenever an outgoing message containing an Ack' is received by SSL system 1000 from the server, SSL system 1000 replaces the Ack' with the sequence number of the "backup state" (i.e., InBackSeq) or the sequence number of the "forward state" (i.e., InMaxSeq). SSL system 1000 may also update its internal state, and may update the value of the last Ack' it received so far from the server (i.e., OutLastAck'). State transitions possible upon receiving an Ack' are:
[0159] 1. NACCAU or SACCAU: if SSL system 1000 receives an Ack' for the last information sent (i.e., corresponding to the "forward state"), then SSL system 1000 collapses the "backup state" to the "forward state" and advances the internal state to CAU.
[0160] 2. NACSAC: If SSL system 1000 receives an Ack' for some, but not all of the TCP packets that it has sent to the server, it advances its state to SAC, and updates the value of the last Ack' that it has received.
[0161] The following describes each state transition in Table III in detail.
[0162] Case 1: Ack' refers to information in a TCP packet for which SSL system 1000 has already sent an acknowledgment to the client. SSL system 1000 sends the packet to the client, and sets the ack number to InBackSeq, the next seq number that SSL system 1000 expects after the "backup state."
[0163] Case 2: Ack' refers to information in a TCP packet that SSL system 1000 is expecting next. SSL system 1000 sends the TCP packet to the client, and sets the ack number to InBackSeq, the next seq number that SSL system 1000 expects after the "backup state."
[0164] Case 3: Ack' refers to information that was not sent to SSL system 1000. This is an erroneous packet since the server is acknowledging data that it has not received. SSL system 1000 sends the TCP packet to the client with the same error. That is, it sets the ack number to InBackSeq offset by the same amount that Ack' exceeded InBackSeq'. Then, when the client receives this, it will detect the error and take appropriate steps to correct it.
[0165] Case 4: Ack' refers to information that has already been acknowledged by SSL system 1000 to the client (Ack'.ltoreq.InBackSeq'). SSL system 1000 transmits the TCP packet, and sets the ack number to InBackSeq, the next seq number that SSL system 1000 expects after the "backup state."
[0166] Case 5: Ack' refers to information for which SSL system 1000 has not yet received an acknowledgment, and for which SSL system 1000 has not yet sent an acknowledgment to the client. A transition is made to SAC. OutLastAck' is updated to Ack'. Then, SSL system 1000 transmits the TCP packet to the client, and sets the ack number to InBackSeq. SSL system 1000 reverts to InBackSeq because it can decrypt the packet with seq number InBackSeq (SSL system 1000 would use the "backup state" information stored in the SSL Connection State). If SSL system 1000 were to set the ack number in the TCP packet to the ack number corresponding to Ack', and the packet got lost and was later retransmitted, SSL system 1000 would not be able to decrypt it.
[0167] Case 6: Ack' refers to the next seq number that SSL system 1000
expects to receive from the client after the "forward state." This means that the server has acknowledged receipt of all information sent by SSL system 1000 to the server. A transition is made to CAU, the "forward state" becomes the "backup state," and SSL system 1000 transmits the TCP packet to the client with the ack number set to InMaxSeq, the next seq number that SSL system 1000 expects to receive from the client after the "forward state."
[0168] Case 7: Ack' refers to information that SSL system 1000 has not yet sent (this is just like case 3, an erroneous packet). However, a transition is made to CAU, the "forward state" becomes the "backup state," and SSL system 1000 transmits the TCP packet to the client with the ack number reset to the seq number expected after the "forward state" offset by the same amount that Ack' exceeds InMaxSeq'.
[0169] Case 8: Ack' refers to information in a TCP packet for which SSL system 1000 has already sent an acknowledgment to the client. SSL system 1000 sends the packet to the client, and sets the ack number to InBackSeq, the next seq number that SSL system 1000 expects after the "backup state."
[0170] Case 9: Ack' refers to information in a TCP packet that SSL system 1000 is expecting next after the "backup state." SSL system 1000 sends the TCP packet to the client, and sets the ack number to InBackSeq, the next seq number that SSL system 1000 expects after the "backup state."
[0171] Case 10: Ack' refers to information for which SSL system 1000
already received an acknowledgment. SSL system 1000 transmits the TCP packet to the client, and sets the ack number to InBackSeq. SSL system 1000 reverts to InBackSeq because it can decrypt the packet with seq number InBackSeq (SSL system 1000 would use the "backup state" information stored in the SSL Connection State). If SSL system 1000 were to set the ack number in the TCP packet to the ack number corresponding to Ack', and the packet got lost and was later retransmitted, SSL system 1000 would not be able to decrypt it.
[0172] Case 11: Ack' refers to information for which SSL system 1000 has not yet received an acknowledgment, and for which SSL system 1000 has not yet sent an acknowledgment to the client. OutLastAck' is updated to Ack'. Then, SSL system 1000 transmits the TCP packet to the client, and sets the ack number to InBackSeq. SSL system 1000 reverts to InBackSeq because it can decrypt the packet with seq number InBackSeq (SSL system 1000
would use the "backup state" information stored in the SSL Connection State). If SSL system 1000 were to set the ack number in the TCP packet to the ack number corresponding to Ack', and the packet got lost and was later retransmitted, SSL system 1000 would not be able to decrypt it.
[0173] Case 12: Ack' refers to the next seq number that SSL expects to receive from the client after the "forward state." A transition is made to CAU, the "forward state" becomes the "backup state," and SSL system 1000 transmits the TCP packet to the client with the ack number set to InMaxSeq, the next seq number that SSL system 1000 expects to receive from the client after the "forward state."
[0174] Case 13: Ack' refers to information that SSL system 1000 has not yet sent (this is just like cases 3 and 7, an erroneous packet). However, a transition is made to CAU, the "forward state" becomes the "backup state," and SSL system 1000 transmits the TCP packet to the client with the ack number reset to the seq number expected after the "forward state," offset by the same amount that Ack' exceeds InMaxSeq'.
Table IV
[0175] Before describing each state transition in detail in conjunction with Table IV, the following provides an overview.
[0176] Whenever an incoming message containing encrypted data is received by SSL system 1000 from the client, it could belong to one of the following categories: (a) a new, in-order packet; (b) a new, out-of-order packet; (c) a complete, in-order retransmit (i.e., it contains no new data); (d) a partial, in-order retransmit (i.e., some old data and some new data); and (e) an out-of-order retransmit.
[0177] SSL system 1000 determines the category of an incoming TCP packet by comparing the packet's sequence number with the sequence numbers of the "forward state" and the "backup state." Out-of-order packets are dropped in accordance with this embodiment of the present invention, but could be reassembled in alternative embodiments. In-order packets are processed using the "backup state" (i.e., InBackSeq) if it is a retransmit, or using the "forward state" (i.e., InMaxSeq) if it is a new packet. The state transitions possible upon receiving an incoming TCP packet are:
[0178] 1. SACNAC: if SSL system 1000 receives a retransmit of a packet that has been Acked by the server (but not by SSL system 1000 to the client), then SSL system 1000 transitions from the SAC to the NAC state.
[0179] 2. CAUNAC: On arrival of a new, in-order packet, SSL system 1000
transitions from the CAU state to the NAC state.
[0180] The following describes each state transition in Table IV in detail.
[0181] Case 1: Seq refers to information for which SSL system 1000 has already received an acknowledgment from the server and sent the acknowledgment to the client. This retransmit was probably caused by a loss of an Ack sent by SSL system 1000 to the client, and hence, the subsequent retransmission by the client. SSL system sends a ReACK request to the server (see Note 2 following Table IV). The ReACK request causes the server to resend an acknowledgment, which acknowledgment is passed to the client.
[0182] Case 2: Seq refers to new, in-order information that SSL system 1000 has not yet received. SSL system 1000 processes the information (i.e., decrypts it and verifies the signature), and sends the decrypted information to the server. Also, it updates InMaxSeq to the next expected sequence number, and changes the state of the system to NAC.
[0183] Case 3: Seq refers to new, but out-of-order information. In accordance with this embodiment of the present invention, SSL system 1000
drops this information.
[0184] Case 4: This case is handled in the same manner that case 1 is handled.
[0185] Case 5: Seq refers to a retransmit of information that SSL system 1000 processed earlier, but for which SSL system 1000 has not yet received an ack. This information may be lost between SSL system 1000 and the server. SSL system 1000 processes the information and sends it to the server. However, SSL system 1000 does not update the "backup state" because it has not yet received an ack for this packet.
[0186] Case 6: Seq refers to retransmitted information, but not the next expected information. Since SSL system 1000 does not have the SSL connection state information to enable it to be processed, as a result, the retransmitted information is simply turned into a ReACK request to update OutLastAck' (i.e., the last Ack received by SSL system 1000).
[0187] Case 7: Seq refers to new, in-order information. This case is handled in the same that case 2 is handled.
[0188] Case 8: This case is handled in the same manner that case 3 is handled.
[0189] Case 9: This case is handled in the same manner that cases 1 and 4
are handled.
[0190] Case 10: Seq refers to a retransmission of information that SSL system 1000 processed earlier, and for which information SSL system 1000
has received an ACK from the server. SSL system 1000 processes the information, and advances the "backup state" (i.e., InBackSeq, InBackSeq') to the new information. If the value of seq' plus the length of the decrypted information is equal to the last ack received (i.e., OutLastAck'), the SSL system 1000 state is updated to NAC, otherwise, SSL system 1000 continues to be in the SAC state.
[0191] Case 11: Seq refers to a retransmission of information for which SSL system 1000 has not yet received an ack from the server. This case is handled in the same manner that case 5 is handled.<