Patent Description:
Embodiments of the present disclosure relate generally to computer science and networking and, more specifically, to sharing secure communication sessions within a computer network.

Secure communication protocols, such as Transport Layer Security (TLS), are commonly used to secure communications over computer networks. Typically, secure communication sessions, such as TLS sessions, are initiated with a "handshake. " During the handshake, a client application and a server first verify each other and then negotiate a session encryption key (also referred to herein as a "session key") that is used to encrypt and decrypt communications between the client application and the server during a session. Any entity, such as a malicious actor, that does not possess the session key is not able to decrypt communications between the client application and the server during the session.

The handshakes used to initiate secure communication sessions can be expensive, both computationally and in terms of the amount of time required to perform the handshakes. To avoid expensive handshakes, some secure communications protocols permit a server to encrypt session keys and other information associated with a session using another encryption key that is maintained by that server. The encrypted session key and other information are then returned to the client application as a "ticket" (also referred to herein as a "session ticket"), which the client application can present to the server at a later point in time to resume the secure communication session with the given server, without having to perform a new handshake. For example, in TLS, a ticket is a "blob" of data that is opaque to the client application and includes an encrypted session key along with other session information. The blob can be decrypted by the server that initially encrypted the blob using the same encryption key. The decrypted information can then be used to rebuild a session-specific state for a previously-generated secure communication session between the client application and the given server, which enables the secure communication session to be automatically resumed without having to perform another handshake.

One drawback of the above approach is that secure communication sessions can only be resumed between the client application and the same given server. However, web services oftentimes are provided through multiple servers rather than a single server. In such cases, a client application must perform a separate handshake with each server to establish the necessary sessions across the different servers to access the relevant web service. A session established with one server cannot be shared with or restored on another server. As noted above, performing multiple handshakes with different servers can be computationally expensive and require significant amounts of time.

As the foregoing illustrates, what is needed in the art are more effective techniques for establishing secure communication sessions within a computer network.

<CIT> describes systems, devices, and methods for using TLS session resumption tickets to store and manage information about objects that a server or a set of servers has previously delivered to a client and therefore that the client is likely to have in client-side cache. When communicated to a server later, this information can be used to drive server decisions about whether to push an object to a client, e.g., using an HTTP/<NUM> server push function or the like, or whether to send an early hint to the client about an object.

The invention to which this European patent is directed is defined by the appended claims. One embodiment of the present disclosure sets forth a computer-implemented method for sharing secure communication sessions within a computer network. The method includes receiving a first ticket from a first server that is included in a first server pool and with which a first secure communication session has been established. The method further includes receiving information indicating that a second server also is included in the first server pool and is associated with a first address. In addition, the method includes establishing a connection with the second server based on the first address, and restoring the first secure communication session with the second server based on the first ticket.

Another embodiment of the present disclosure sets forth a computer-implemented method. The method includes storing associations between servers and server pools, wherein servers in each server pool share an encryption key that is used to encrypt session keys. The method further includes transmitting, to a client application, information indicating an address of a first server from which content can be accessed and a first server pool associated with the first server.

Another embodiment of the present disclosure sets forth a system. The system includes a memory storing a client application. The system further includes a processor that is coupled to the memory and, when executing the client application, is configured to perform the steps of: receiving a ticket from a first server that is included in a server pool and with which a secure communication session has been established, receiving information indicating that a second server also is included in the server pool and is associated with an address, establishing a connection with the second server based on the address, and restoring the secure communication session with the second server based on the ticket.

At least one technical advantage of the disclosed techniques relative to the prior art is that multiple handshakes are not required to establish secure communication sessions with servers in a server pool. As a result, the computational expense and time generally associated with handshakes can be avoided when accessing content stored across a server pool. Further, different shared encryption keys can be generated for different server pools so that, even if the shared encryption key for one server pool is compromised, the compromised shared encryption key cannot be used to decrypt data handled by other server pools. In addition, the servers in different server pools can use shared encryption keys having different expiration times, which provides resiliency by ensuring that encryption keys do not expire across all server pools at the same time in cases when key rotation fails and enables the failure to be remedied before the encryption keys do all expire. These technical advantages represent one or more technological advancements over prior art approaches.

In the following description, numerous specific details are set forth to provide a more thorough understanding of the present disclosure. However, it will be apparent to one skilled in the art that the present disclosure may be practiced without one or more of these specific details.

As described, conventional approaches for resuming secure communication sessions only permit sessions to be resumed with the same server. Oftentimes, web services are provided by multiple servers rather than a single server. In such cases, a client application must perform a separate handshake to establish a secure communication session with each of the multiple servers, which can be computationally expensive and require a significant amount of time.

The disclosed techniques permit secure communication sessions to be shared across multiple servers belonging to a server pool. In the disclosed techniques, the servers in a server pool share a centrally-generated encryption key that is used to encrypt session keys in tickets that are returned to client applications. The shared encryption key (which is also referred to herein as a "pool encryption key") is associated with a first time period during which the shared encryption key can be used to both encrypt and decrypt session keys, as well as a longer time period during which the shared encryption key can be used only to decrypt (but not to encrypt) session keys. In some embodiments, the shared encryption keys generated for a server pool have staggered expiration times, such that a next shared encryption key can be used to encrypt tickets after a previous shared encryption key expires. The staggered expiration times of shared encryption keys is also referred to herein as a "waterfall scheme. " In some embodiments, the shared encryption keys for different server pools (e.g., server pools at different geographical locations) can be valid for different periods of time.

When a client application first establishes a secure communication session with a server belonging to a particular server pool, the server returns a ticket that includes an encrypted version of a session key generated using a shared encryption key for the server pool. The client application stores the ticket and an association between the server pool and the ticket in a cache. Prior to an expiration of the ticket, the client application can retrieve the ticket from the cache and present the ticket to another server in the same server pool to restore the secure communication session with the other server. The associations between servers and server pools can be communicated to the client application in any technically feasible manner, such as part of information indicating servers from which content can be accessed or via the Domain Name System (DNS).

Advantageously, the disclosed techniques address various limitations of conventional approaches for resuming secure communication sessions. The disclosed techniques do not require multiple handshakes to establish secure communication sessions with servers in a server pool. As a result, the computational expense and time generally associated with handshakes can be avoided when accessing content stored across a server pool. Further, different shared encryption keys can be generated for different server pools so that, even if the shared encryption key for one server pool is compromised, the compromised shared encryption key cannot be used to decrypt data handled by other server pools. In addition, the shared encryption keys for different server pools can have different expiration times, which provides resiliency by ensuring that the shared encryption keys do not expire across all server pools at the same time in cases when key rotation fails and enables such a failure to be remedied before the shared encryption keys do all expire.

<FIG> is a conceptual illustration of a system <NUM> that is configured to implement one or more aspects of the various embodiments. As shown, the system <NUM> includes a client application <NUM>, a manifest server <NUM>, and pools <NUM> and <NUM> of content servers <NUM><NUM>-N (collectively referred to as content servers <NUM> and individually referred to as a content server <NUM>) and <NUM><NUM>-M (collectively referred to as content servers <NUM> and individually referred to as a content server <NUM>), respectively, that communicate over a network <NUM>, such as the Internet. In addition, the system <NUM> includes a key generator <NUM> that is in communication with the content servers <NUM> and <NUM>.

The content servers <NUM> and <NUM> serve data associated with content to client applications, such as the client application <NUM>. For example, a streaming video service could include content servers that serve video, audio, and subtitle data. More generally, the content servers <NUM> and <NUM> can serve any suitable data to client applications. In some embodiments, each of the content servers <NUM> and <NUM> can store different content data. In other embodiments, one or more of the content servers can store the same content data. Although described herein primarily with respect to content servers <NUM> and <NUM>, techniques disclosed herein are also applicable to other types of servers.

The client application <NUM> can be a web browser or any other technically feasible software application that is capable of accessing content stored on the content servers <NUM> (and/or other servers). For example, the client application <NUM> could be a dedicated application for browsing and watching streaming videos.

The manifest server <NUM> stores information indicating which content server(s) <NUM> and <NUM> the client application <NUM> should communicate with to access various content data stored on the content servers <NUM> and <NUM>, as well as server pools to which those content servers <NUM> and <NUM> belong. Returning to the streaming video example, the video, audio, and subtitle data associated with videos could be stored across different content servers <NUM> and <NUM>. As another example, different content servers <NUM> and <NUM> could store video data that is encoded differently (e.g., at different bit rates). In such cases, the manifest server <NUM> can maintain information (e.g., metadata) indicating where video, audio, and subtitle data is stored across the content servers <NUM> and <NUM>. In addition, the manifest server <NUM> can provide, to the client application <NUM>, information relating to content servers <NUM> and/or <NUM> where data for particular videos can be accessed, including the addresses of those content servers <NUM> and/or <NUM> and identifiers (IDs) of server pools to which the content servers <NUM> and/or <NUM> belong. The addresses of the content server <NUM> and/or <NUM> can include web addresses, also referred to as uniform resource locators (URLs), Internet Protocol (IP) addresses, or the like. Such information indicating where data relating to particular content can be accessed on the content servers <NUM> and/or <NUM> is also referred to herein as a "manifest.

In some embodiments, the client application <NUM> requests, in response to user input, the information relating to content servers <NUM> from which particular content can be accessed. Returning to the streaming video example, a user may select to watch a particular video, in which case the client application <NUM> could request from the manifest server <NUM> information relating to content servers <NUM> from which data (e.g., video, audio, subtitles) for the selected video can be accessed.

In some embodiments, the client application <NUM> can also use predictive technique(s) to automatically determine that a user is likely to request content from certain content server(s), and request information relating to those content server(s). Any technically feasible predictive technique(s) (e.g., machine learning techniques) may be employed. For example, the client application <NUM> could perform prefetching in which the client application 102determines particular video(s) that a user is likely to select when the client application <NUM> is started, as well as the content servers <NUM> and/or <NUM> on which data associated with those video(s) are stored.

In response to the request from the client application <NUM> the manifest server <NUM> transmits, to the client application <NUM>, content server information including addresses of content servers <NUM> and/or <NUM> and IDs of server pools to which those content servers belong. In alternative embodiments, anycast may be employed, in which a single hostname points to multiple content servers that belong to a content server pool. In such cases, information indicating the server pools to which the content servers <NUM> and/or <NUM> belong may not be transmitted to the client application <NUM>, which may even be unaware that the server pools exist. It should be understood that the client application <NUM> in such cases is unable to select particular content servers based on, e.g., geographical location. Instead, particular content servers can be selected by DNS, which processes the anycast requests. In some embodiments, a pool of servers can be associated with a single DNS entry, but anycast may not be used (i.e., anycast is optional). By contrast, in embodiments in which the manifest server <NUM> transmits information indicating the server pools to which content servers belong, the client application <NUM> can select and communicate with particular content servers via unicast. It should be understood that the client application <NUM> in some embodiments may select servers belonging to server pools for which pool encryption keys have been cached, because secure communication sessions can be restored relatively quickly with those servers. Although described herein primarily with respect to the manifest server <NUM> transmitting information indicating the server pools to which content servers belong, in other embodiments, such information can be transmitted to the client application <NUM> in any technically feasible manner, such as via DNS.

In some embodiments, the client application <NUM> receives manifests including addresses of content servers <NUM> and/or <NUM> from which data relating to content can be accessed, and server pools to which those content servers <NUM> and/or <NUM> belong. The client application <NUM> can use such addresses to communicate with the content servers <NUM> and/or <NUM>. In addition, the client application <NUM> can use stored session tickets to restore sessions with content servers <NUM> and/or <NUM> belonging to server pools associated with the stored session tickets. As shown, the client application <NUM> includes a ticket cache <NUM> that stores session tickets and associations between session tickets and server pools. In some embodiments, IDs of the server pools are used as keys into the ticket cache <NUM>.

For explanatory purposes only, one client application <NUM>, one manifest server <NUM>, two pools <NUM> and <NUM> of content servers <NUM> and <NUM>, and one key generator <NUM> are shown in <FIG>. However, as persons skilled in the art will recognize, the system <NUM> may generally include any number of client applications, and each of the client application <NUM>, the manifest server <NUM>, the content servers <NUM> and <NUM>, and the key generator <NUM>, may run on one or more physical computing systems or virtual computing systems running in, e.g., a data center or cloud. Further, functionality of the client application <NUM>, the manifest server <NUM>, the content servers <NUM> and <NUM>, and the key generator <NUM> may be distributed across any number of other computing devices, or functionality of any number of applications may be consolidated into a single application or subsystem.

<FIG> is a conceptual illustration of a manifest <NUM> that can be generated by the manifest server <NUM> of <FIG>, according to various embodiments. As shown, the manifest <NUM> includes information relating to content servers (e.g., one or more of the contents servers <NUM> or <NUM>) from which particular content can be downloaded by the client application <NUM>. Returning to the video streaming example, the particular content could be a video that a user has selected to watch or is likely to select to watch, as determined via predictive algorithm(s). In such a case, the video, audio, and subtitle data that is associated with the video and applicable to a client device on which the client application <NUM> is running, could be stored across multiple content servers. For example, different content servers could store video data encoded at different bit rates or subtitles in different languages.

Illustratively, the manifest server <NUM> generates the manifest <NUM> to include content server addresses <NUM>, <NUM>, and <NUM> from which particular content can be downloaded by the client application <NUM>, as well as pool identifiers (IDs) <NUM> and <NUM> indicating the server pools to which those content servers belong. In some embodiments, the content server addresses <NUM>, <NUM>, and <NUM> included in the manifest <NUM> may be associated with content servers that host content specific to a client device on which the client application <NUM> runs. For example, one or more of the content servers could store videos having a particular resolution that can be played back on the client device. Although not shown, the manifest <NUM> can also include other suitable information, such as information specifying the content data (e.g., video, audio, and/or subtitles) stored on particular content servers.

Upon receiving the manifest <NUM>, the client application <NUM> can use a session ticket that is received from a content server <NUM> or <NUM> after performing a handshake, and is stored in the ticket cache <NUM>, to restore a session with another content server <NUM> or <NUM> that belongs to the same server pool <NUM> or <NUM>. In particular, the client application <NUM> can present the session ticket to the other content server, which can decrypt the session ticket using the pool encryption key that was used to encrypt the session key. The decrypted information can then be used to rebuild a session-specific state for a previously-generated secure communication session. Doing so restores the previous session that was initiated with a secure communication handshake, without requiring the handshake to be performed again. If, however, a session ticket associated with the pool ID <NUM> or <NUM> is not stored in the ticket cache <NUM>, then the client application <NUM> must perform another secure communication handshake with the content server <NUM> or <NUM> to initiate a new session. Such a content server can then (<NUM>) generate a ticket for the new session by encrypting a session key (and other information needed to restore the session) using a pool encryption key received from the key generator <NUM>, and (<NUM>) transmit the session ticket to the client application <NUM>. In turn, the client application <NUM> can store the session ticket in the ticket cache <NUM> for future use with the same content server and/or other content servers belonging to the same server pool.

<FIG> illustrates in greater detail the ticket cache <NUM> in the client application <NUM> of <FIG>, according to various embodiments. As described, the ticket cache <NUM> is used by the client application <NUM> to store session tickets for different content server pools. Illustratively, the ID of server pools <NUM>, <NUM>, and <NUM> are used as keys into the ticket cache <NUM>. In some embodiments, the ticket cache <NUM> can be a database. As shown in <FIG>, multiple session tickets <NUM>, <NUM>, and <NUM> are stored, along with associated server pool IDs <NUM>, <NUM>, and <NUM>, respectively. Although three session tickets <NUM>, <NUM>, and <NUM> are shown for illustrative purposes, the ticket cache <NUM> can generally store any number of session tickets and associated server pool IDs. It should be noted that the associations between servers and server pools do not need to be stored in the ticket cache <NUM> (although the associations could also be cached), because such associations are transmitted by the manifest server <NUM> to the client application <NUM> in response to requests from the client application <NUM> for information relating to content servers from which data for particular content can be accessed.

As described, the server pool IDs <NUM>, <NUM>, and <NUM> are keys that can be used to retrieve the session tickets <NUM>, <NUM>, and <NUM> from the ticket cache <NUM>. In some embodiments, the session tickets <NUM>, <NUM>, and <NUM> expire at the same time that the server pool encryption keys used to generate those session tickets expire and can no longer be used for encryption or decryption. As described, different server pools can also be associated with different pool encryption keys, and the pool encryption keys can expire in a staggered manner. As a result, even if the pool encryption key for one server pool is compromised, that pool encryption key cannot be used to decrypt data handled by other server pools. In addition, staggering the expiration times of pool encryption keys provides resiliency by ensuring that the pool encryption keys do not expire across all server pools at the same time when key rotation fails and enables such a failure to be remedied before the pool encryption keys do all expire.

In some embodiments, the client application <NUM> does not maintain the expiration times of session tickets. In such cases, the client application <NUM> may attempt to establish a connection with a server using a session ticket without checking or knowing whether the session ticket has expired. If the session ticket has in fact expired, then the server will require a new secure communication session to be established via a full handshake and provide to the client application <NUM> an updated session ticket associated with the new session.

<FIG> is a conceptual illustration of a server machine in which the manifest server <NUM> and key generator <NUM> of <FIG> are implemented, according to various embodiments. Although described herein with respect to the server <NUM>, it should be understood that the manifest server <NUM> can generally run on any technically feasible computing device that is connected to a network, such as the Internet. As shown, the server <NUM> includes, without limitation, a processor <NUM> and a memory <NUM>. The processor <NUM> may be any instruction execution system, apparatus, or device capable of executing instructions. For example, the processor <NUM> could comprise a central processing unit (CPU), a graphics processing unit (GPU), a controller, a microcontroller, a state machine, or any combination thereof. The memory <NUM> stores content, such as software applications and data, for use by the processor <NUM>.

The memory <NUM> may be one or more of a readily available memory, such as random access memory (RAM), read only memory (ROM), floppy disk, hard disk, or any other form of digital storage, local or remote. In some embodiments, a storage (not shown) may supplement or replace the memory <NUM>. The storage may include any number and type of external memories that are accessible to the processor <NUM>. For example, and without limitation, the storage may include a Secure Digital Card, an external Flash memory, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

As shown, the memory <NUM> stores the manifest server <NUM>, the key generator <NUM>, and an operating system <NUM> on which the manifest server <NUM> and the key generator <NUM> run. The operating system <NUM> may be, e.g., Linux®, Microsoft Windows®, or Android™. The manifest server <NUM> and the key generator <NUM> may be a service, application, or other type of software that runs on the operating system <NUM>. For example, in some embodiments, the manifest server <NUM> and the key generator <NUM> may be microservices in a video streaming service (or other type of service) having a microservice architecture. Further, functionality of the manifest server <NUM> and the key generator <NUM> may be distributed across multiple pieces of software in some embodiments. In addition, although shown as running on the same server <NUM>, the manifest server <NUM> and the key generator <NUM> may run on different computing devices in other embodiments.

In some embodiments, the key generator <NUM> generates and distributes pool encryption keys for content server pools. As described, different pool encryption keys can be generated for different server pools so that, even if the pool encryption key for one server pool is compromised, that pool encryption key cannot be used to decrypt data handled by other server pools. Each of the pool encryption keys is associated with (<NUM>) a first time period during which the pool encryption key can be used to encrypt and decrypt session keys, and (<NUM>) a longer time period during which the pool encryption key can be used only to decrypt (but not to encrypt) session keys. For example, a pool encryption key could be valid for encryption and decryption for <NUM> hours, and only for decryption for <NUM> hours. In some embodiments, each pool encryption key associated with a server pool is assigned a first timestamp when the pool encryption key can start being used for encryption and decryption, allowing the pool encryption key to be pre-staged in advance of use, and a second timestamp when the pool encryption key expires and can no longer be used for decryption. In such cases, the end of the first time period, after which the pool encryption key can no longer be used to encrypt session keys but can still be used to decrypt session keys, is implied if another pool encryption key is available with a valid first timestamp for starting encryption and decryption. In addition, the expiration time of the pool encryption key ensures that, even if a malicious actor obtains a pool encryption key, that pool encryption key can only be used to decrypt session tickets for a limited period of time (e.g., <NUM> hours). In some embodiments, a waterfall scheme is used to stagger the expiration times of pool encryption keys. For example, after a pool encryption key is no longer valid for encryption after a <NUM>-hour period, but while the pool encryption key is still valid for decryption, a next pool encryption key could be valid for encryption. In some embodiments, the pool key expiration times also differ across server pools, which can provide resiliency by ensuring that pool encryption keys do not all expire at the same time if key rotation fails. Returning to the example above, the <NUM>-hour period during which a pool encryption key for one server pool can be used to encrypt session keys to generate session tickets and decrypt those session tickets could last from midnight of one day to midnight of the next day, while the <NUM>-hour period during which a pool encryption key for another server pool can be used to encrypt session keys to generate session tickets and decrypt those session tickets could last from thirty minutes past midnight of one day to thirty minutes past midnight of the next day, etc..

In some embodiments, the manifest server <NUM> stores information indicating which content server(s) <NUM> and/or <NUM> the client application <NUM> should communicate with in order to access various content data stored on the content servers <NUM> and/or <NUM>. In response to a request from the client application <NUM> for information relating to content servers from which particular content can be accessed, the manifest server transmits, to the client application <NUM>, information specifying (<NUM>) addresses associated with the content servers from which data for the particular content can be accessed, and (<NUM>) associated content server pools, as discussed in greater detail below in conjunction with <FIG>.

<FIG> is a conceptual illustration of a client device <NUM> in which the client application <NUM> of <FIG> is implemented, according to various embodiments. Although described herein with respect to the client device <NUM>, it should be understood that the client application <NUM> can generally run on any type of computing device that is connected to a network, such as the Internet. As shown, the client device <NUM> includes a processor <NUM> and a memory <NUM>, which may perform similar functionalities as the processor <NUM> and the memory <NUM>, respectively, of the server <NUM> described above in conjunction with <FIG>. In some embodiments, a storage (not shown) may supplement or replace the memory <NUM>.

As shown, the memory <NUM> stores the client application <NUM> and an operating system <NUM>, which is similar to the operating system <NUM> described above in conjunction with <FIG>. In some embodiments, the client application <NUM> receives manifests including addresses of content servers <NUM> and/or <NUM>, from which data relating to particular content can be accessed, as well as information specifying server pools to which the content servers <NUM> and/or <NUM> belong. In alternative embodiments, information specifying server pools to which content servers <NUM> and/or <NUM> belong can be received in any other technically feasible manner, such as via DNS. In some embodiments, the server pools to which content servers <NUM> and/or <NUM> belong can also be inferred by the client application <NUM> itself, such as via a consistent hash. The client application <NUM> can use the addresses in the manifest to communicate with particular content servers <NUM> and/or <NUM>. In addition, the client application <NUM> can use stored session tickets to restore sessions with content servers <NUM> and/or <NUM> belonging to the same server pools, as discussed in greater detail below in conjunction with <FIG>. As shown, the client application <NUM> includes the ticket cache <NUM>, which as described stores session tickets and associations between the session tickets and server pools.

<FIG> is a flow diagram of method steps for the key generator <NUM> to generate and distribute pool encryption keys for generating session tickets, according to various embodiments. Although the method steps are described with reference to the systems of <FIG>, persons skilled in the art will understand that any system configured to implement the method steps, in any order, falls within the scope of the present disclosure.

As shown, a method <NUM> begins at step <NUM>, where the key generator <NUM> generates pool encryption keys for content server pools based on a waterfall scheme. As described, different pool encryption keys can be generated for different content server pools, and each of the pool encryption keys can be associated with a first time period during which the pool encryption key can be used to encrypt and decrypt session keys, as well as a longer time period during which the pool encryption key can be used only to decrypt session keys. Further, the waterfall scheme is used to stagger the time periods for server pools in, e.g., different geographical locations. As described, doing so can provide resiliency by ensuring that pool encryption keys do not expire across all content server pools at the same time so that some server pools are still accessible even if others become unavailable as a result of a failure during key rotation.

At step <NUM>, the key generator <NUM> receives requests for pool encryption keys from the content servers <NUM> and <NUM>. For example, the content servers <NUM> and <NUM> could request new pool encryption keys before previous pool encryption keys expire.

At step <NUM>, the key generator <NUM> distributes the pool encryption keys to the content servers in response to the requests. The key generator <NUM> can also transmit information indicating the expiration times (and starting times) associated with the pool encryption keys, described above in conjunction with <FIG>.

<FIG> is a flow diagram of method steps for the manifest server <NUM> to generate and transmit a manifest to the client application <NUM>, according to various embodiments. Although the method steps are described with reference to the systems of <FIG>, persons skilled in the art will understand that any system configured to implement the method steps, in any order, falls within the scope of the present disclosure.

As shown, a method <NUM> begins at step <NUM>, where the manifest server <NUM> receives a request from the client application <NUM> for information relating to content servers from which data for particular content can be accessed. As described, the client application <NUM> can make such a request in response to user input, or to identifying content that a user is likely to request via predictive technique(s).

At step <NUM>, the manifest server <NUM> determines the information relating to the content server(s) <NUM> and/or <NUM> hosting data associated with the particular content. As described, the manifest server <NUM> stores information indicating which content servers <NUM> can be used to access data, such as video, audio, subtitles, etc. for content, such as a streaming video. In turn, the manifest server <NUM> can determine the addresses of content server(s), e.g., web addresses and/or IP addresses, and the associated server pool(s), e.g., ID(s) of such server pool(s), that provide access to data associated with particular content.

At step <NUM>, the manifest server <NUM> transmits, to the client application <NUM>, a manifest indicating addresses of the content server(s) and server pools to which the content server(s) belong. As described, the manifest can include information relating to the content server(s) determined at step <NUM>, including the addresses of those content server(s) and associated server pool ID(s). Although described herein primarily with respect to the manifest server <NUM> transmitting information indicating the server pools to which content servers belong, in other embodiments, such information can be transmitted to the client application <NUM> in any technically feasible manner, such as via DNS, or be inferred by the client application <NUM> itself.

<FIG> is a flow diagram of method steps for the client application <NUM> to communicate with one of the content servers <NUM> or <NUM>, according to various embodiments. Although the method steps are described with reference to the systems of <FIG> and <FIG>, persons skilled in the art will understand that any system configured to implement the method steps, in any order, falls within the scope of the present disclosure.

As shown, a method <NUM> begins at step <NUM>, where the client application <NUM> receives a manifest from the manifest server <NUM>. In some embodiments, the received manifest is the manifest transmitted by the manifest server <NUM> at step <NUM>, described above in conjunction with <FIG>. As described, such a manifest includes information relating to the content server(s), including addresses of the content server(s) and server pool(s) to which the content server(s) belong. In alternative embodiments, information indicating server pool(s) to which content server(s) can be received by the client application <NUM> in other ways, such as via DNS, or inferred by the client application <NUM> itself.

At step <NUM>, the client application <NUM> determines a content server <NUM> or <NUM> from which to request data, and a server pool to which the content server <NUM> or <NUM> belongs, based on the manifest. Although described with respect to a single content server for simplicity, it should be understood that steps <NUM> through <NUM> of the method <NUM> can be repeated by the client application <NUM> any number of times to communicate with different content servers.

At step <NUM>, the client application <NUM> determines whether a session ticket for the server pool is cached. As described, the client application <NUM> store can session tickets for different content server pools in the ticket cache <NUM>, with the pool ID being used as a key into the ticket cache <NUM>.

If a session ticket for the server pool is cached, then at step <NUM>, the client application <NUM> retrieves the session ticket for the server pool from the ticket cache <NUM>. Thereafter, at step <NUM>, the client application <NUM> attempts to restore a session with the content server <NUM> or <NUM> using the retrieved session ticket. If the session is successfully restored, then the client application <NUM> can access content data hosted by the content server <NUM> or <NUM>.

On the other hand, if the client application <NUM> determines at step <NUM> that a session ticket for the server pool is not cached, or if the client application <NUM> receives, at step <NUM>, a notification from the content server <NUM> or <NUM> that the cached session ticket for the server pool has expired, then, at step <NUM>, the client application <NUM> negotiates a new session with the content server <NUM> or <NUM>. The negotiation can include performing a handshake according to a secure communication protocol, such as TLS. After establishing the new session, the client application <NUM> can access content data hosted by the content server <NUM> or <NUM>.

At step <NUM>, the client application <NUM> further receives, from the content server <NUM> or <NUM>, a session ticket for the server pool to which the content server belongs. It should be understood that the content application <NUM> knows which server pool the content server <NUM> or <NUM> belongs to, as such information is indicated in the manifest received from the manifest server <NUM> (or received in another manner such as via DNS or inferred by the client application <NUM> itself).

Then, at step <NUM>, the client application <NUM> stores the session ticket for the server pool in the ticket cache <NUM>. As described, the session ticket can thereafter be retrieved from the ticket cache <NUM> and used to restore the session with the same content server <NUM> or <NUM> again or with other content server(s) belonging to the same server pool.

At least one technical advantage of the disclosed techniques relative to the prior art is that multiple handshakes are not required to establish secure communication sessions with servers in a server pool. As a result, the computational expense and time generally associated with handshakes can be avoided when accessing content stored across a server pool. Further, different server pools can use different shared encryption keys so that, even if the shared encryption key for one server pool is compromised, the compromised shared encryption key cannot be used to decrypt data handled by other server pools. In addition, the servers in different server pools can use shared encryption keys having different expiration times, which provides resiliency by ensuring that shared encryption keys do not expire across all server pools at the same time in cases when key rotation fails and enables the failure to be remedied before the shared encryption keys do all expire. These technical advantages represent one or more technological advancements over prior art approaches.

Any and all combinations of any of the claim elements recited in any of the claims and/or any elements described in this application, in any fashion, fall within the contemplated scope of the present disclosure and protection.

Aspects of the present embodiments may be embodied as a system, method or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a ""module" or "system. " Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Such processors may be, without limitation, general-purpose processors, special-purpose processors, application-specific processors, or field-programmable gate arrays.

Claim 1:
A computer-implemented method for sharing secure communication sessions within a computer network, the method comprising:
receiving a first ticket from a first server that is included in a first server pool and with which a first secure communication session has been established, wherein the first ticket is generated by the first server encrypting a first session key using a first shared encryption key, wherein the first shared encryption key is used by a first plurality of servers included in the first server pool to encrypt and decrypt one or more session keys; and wherein
a second ticket is generated by encrypting a second session key using a second shared encryption key that is used by a second plurality of servers included in a second server pool to encrypt and decrypt one or more other session keys;
receiving information indicating that a second server also is included in the first plurality of servers and is associated with a first address;
establishing a connection with the second server based on the first address; and
restoring the first secure communication session with the second server using the first ticket.