Secure sharing of transport layer security session keys with trusted enforcement points

Embodiments of the present invention address deficiencies of the art in respect to security enforcement point operability in a TLS secured communications path and provide a novel and non-obvious method, system and computer program product for the secure sharing of TLS session keys with trusted enforcement points. In one embodiment of the invention, a method for securely sharing TLS session keys with trusted enforcement points can be provided. The method can include conducting a TLS handshake with a TLS client to extract and decrypt a session key for a TLS session with the TLS client traversing at least one security enforcement point. The method further can include providing the session key to a communicatively coupled key server for distribution to the at least one security enforcement point. Finally, the method can include engaging in secure communications with the TLS client over the TLS session.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of network security and more particularly to security enforcement point processing of encrypted data in a communications path.

2. Description of the Related Art

Internet security has increasingly become the focus of information technologists who participate in globally accessible computer networks. In particular, with the availability and affordability of broadband Internet access, even within the small enterprise, many computers and small computer networks enjoy continuous access to the Internet. Notwithstanding, continuous, high-speed access is not without its price. Specifically, those computers and computer networks which heretofore had remained disconnected from the security risks of the Internet now have become the primary target of malicious Internet malfeasors.

To address the vulnerability of computing devices exposed to the global Internet, information technologists intend to provide true, end-to-end security for data in the Internet through secure communications. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols which provide secure communications on the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. There are slight differences between SSL 3.0 and TLS 1.0, but the protocol remains substantially the same. In operation, TLS involves two processing phases. First, there is a key exchange or “handshake” phase, in which the server and client attempt to agree upon an encryption suite to be used for data transmission. Subsequently, a bulk encryption or data transmission phase is carried out in which the desired content is transmitted using the agreed-upon encryption suite.

The secured communications path defined between two TLS endpoints often incorporate one or more security enforcement points such as a virtual private network (VPN)/firewall. Security enforcement points generally are no different than any other computing device excepting that the computing device supporting a security enforcement point hosts logic including program code enabled to support security services such as IP packet filtering, intrusion detection, load balancing and quality of service (QoS) setting management. Yet, where a security enforcement point has been positioned in the midst of a TLS secure communications path, the enforcement point will have no access to cleartext data in traversing data. Consequently, the security function of a security enforcement point in a secure TLS communications path will have become inoperable as most security functions require access to unencrypted, cleartext data.

In response, customers often choose between not running encryption (or at least not for the entire communications path), or running encryption on a hop-by-hop basis so that cleartext is available at the enforcement points. In the latter circumstance, even if the entire communications path has been protected end-to-end in a hop-by-hop configuration, the authentication as a whole is not end-to-end. Rather, a given node authenticates only to the next hop node. Additionally, in the hop-by-hop configuration, the TLS server key and certificate along with the private key and certificate must be stored at each enforcement point—an undesirable outcome.

Other TLS proxy methods have been proposed to provide security gateways and SSL aware enforcement points. These proposals usually involve sharing the private key and certificate of the TLS server endpoint, where the private key is used to monitor the session, or terminating the client to server session in the enforcement point (hop-by-hop encryption). Additionally, yet other key recovery schemes have been proposed to save the keys from TLS session in central key recovery server so that the clear text of the recorded TLS session could be recovered at a later time.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the present invention address deficiencies of the art in respect to security enforcement point operability in a TLS secured communications path and provide a novel and non-obvious method, system and computer program product for the secure sharing of TLS session keys with trusted enforcement points. In one embodiment of the invention, a method for securely sharing TLS session keys with trusted enforcement points can be provided. The method can include conducting a TLS handshake with a TLS client to extract and decrypt a session key for a TLS session with the TLS client traversing at least one security enforcement point. The method further can include providing the TLS session information including the session encryption key to a communicatively coupled key server for distribution to the at least one security enforcement point. Finally, the method can include engaging in secure communications with the TLS client over the TLS session.

In one aspect of the embodiment, the method can include withholding completion of the TLS handshake with the TLS client until receiving confirmation from the coupled key server that the at least one security enforcement point has installed the TLS session information including session key for use in decrypting enciphered data for TLS secured payloads traversing the security enforcement point from the TLS client. Thereafter, the TLS handshake can be completed only once having received the confirmation. In another aspect of the embodiment, providing the TLS session information including session key to a communicatively coupled key server for distribution to the at least one security enforcement point, can include providing the TLS session information including session key to a communicatively coupled key server for distribution to subscribing ones of the at least one security enforcement point, or to requesting ones of the at least one security enforcement point.

In another embodiment of the invention, a secure communications data processing system for securely sharing TLS session keys with trusted enforcement points can be provided. The system can include a TLS endpoint configured for coupling to TLS clients, a key server communicatively coupled to the TLS endpoint, and at least one security enforcement point disposed between the TLS clients and the TLS endpoint. The security enforcement point can include a secure and trusted communicative link with the key server over which TLS session information including session keys for corresponding secure communications paths between the TLS clients and the TLS endpoint are installed in the security enforcement point.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention provide a method, system and computer program product for secure sharing of TLS session information including session keys with trusted enforcement points. In accordance with an embodiment of the present invention, a security enforcement point disposed within a secure communications path such as that defined between TLS endpoints, can establish a secure encrypted session with a key server. Once the secure encrypted session has been established, a TLS session can be established that provides for a secure communications path traversing the security enforcement point. The TLS endpoint for the TLS session can provide its TLS session information with session keys to the key server. Thereafter, the key server can provide on demand to the security enforcement point the TLS session information for the TLS session in order to allow the security enforcement point to decrypt traversing data in the secure communications path.

In this way, unlike the hop-by-hop configuration where the enforcement point maintains a copy of the TLS endpoint session information with session keys, in the instant configuration, neither the private key nor the certificate are stored at the security enforcement point. Rather, the security enforcement points cannot satisfy a request for a TLS session from TLS client, but the security enforcement point only enjoys access to specific TLS sessions as controlled by the central server. In addition, when client certificate authentication is required by the server, the identity of the client can be preserved and protected by the TLS session from the client to the intended TLS server endpoint. Finally, unlike the key recovery method of centrally storing keys and session data, in the instant configuration security enforcement points can enjoy real time access to the cleartext of a TLS session.

In illustration,FIG. 1depicts a network data processing system configured for security enforcement point inspection of encrypted data in a secure, end-to-end communications path. The system can include one or more client computing devices110communicatively coupled to a server computing device130over a computer communications network120. Each of the client computing devices110can include a content browser such as a Web browser and can be configured to establish a TLS session for end-to-end secure communications with the server computing device130, for example a Web server.

One or more security enforcement points140can be positioned intermediately between the client computing devices110and the server computing device130in the midst of the secure communications path. The security enforcement points140can be configured to perform any of several security functions, ranging from packet filtering, content inspection and intrusion detection to load balancing and QoS management. Notably, as shown inFIG. 1, each of the security enforcement points140can be coupled to a key server150in secure, trusted relationship in which each of the security enforcement points140authenticates with the key server150and enjoys a secured communications path with the key server150over which encrypted data can be securely passed between the security enforcement points140and the key server150.

The key server150in turn can be coupled to the server computing device130and, in consequence, can maintain an awareness of the TLS session information170for the TLS secure communications path established between an individual one of the client computing devices110and the server computing device130. In operation, different end-to-end secure communications paths can be established between individual ones of the client computing devices110and the server computing device130. In the course of establishing each of the end-to-end secure communications paths, individual TLS session keys170can be established and provided separately to the key server150. The key server150, in turn, can provide the TLS session information including session keys170to all or selected ones of the security enforcement points140. In this regard, the security enforcement points140either selectively can subscribe to different ones of the TLS sessions including session keys170, or the security enforcement points140can dynamically request the TLS session information including session keys170of the key server150, or the security enforcement points140can receive all of the TLS session information including session keys170.

Thereafter, one or more cleartext payloads160A.1,160A.2,160A.N for respective TLS secured communications paths can be transformed into corresponding encrypted payloads160B.1,160B.2,160B.N and transmitted over the respective TLS secured communications paths to the server computing device130where the encrypted payloads160B.1,160B.2,160B.N can be decrypted into cleartext payloads160A.1,160A.2,160A.N. At each of the security enforcement points140there between, however, the encrypted payloads160B.1,160B.2,160B.N can be decrypted for use in performing associated security functions through the TLS session information including session keys170for each of the TLS secured communications paths. As a result, the intermediately disposed security enforcement points140can perform security functions on decrypted cleartext without requiring knowledge of the client computing devices110and without requiring the client computing devices110to have knowledge of the security enforcement points140.

FIG. 2is an event diagram illustrating a process for secure sharing of TLS session keys with trusted enforcement points. Beginning in path210, an initial handshake message can be transmitted from a TLS client to a TLS endpoint. In path220, the TLS endpoint can return a certificate which provides the public key for the TLS endpoint. Subsequently, in path230the TLS client can use the public key for the TLS endpoint to encrypt a pre-master secret for a proposed TLS secured communication path between the TLS client and the TLS endpoint. Finally, the TLS endpoint in path240can decrypt the pre-master secret using the private key for the TLS endpoint. Both the TLS client and TLS endpoint can independently create the same symmetric session keys based on the pre-master secret that is now known to both the TLS client and TLS endpoint.

In order to delay the transmission of encrypted data across the newly established TLS secured communications path before the enforcement point possesses knowledge of the session, the handshake finished message can be withheld. In particular, either the TLS endpoint can withhold the handshake finished message, or the security enforcement point can withhold the handshake finished message. In either case, in path250, the session key can be provided to the key server along with other session attributes such as the starting initialization vector, one or more selected cipher algorithms, and a session identifier. The key server, in turn, in path260can provide a copy of the session information including session key to each subscribing enforcement point coupled to the key server. In this regard, individual enforcement points can subscribe to receive TLS session information including session keys for one or more corresponding TLS clients. Alternatively, the TLS session information including session keys can be provided to all coupled enforcement points, or the TLS session information including session keys can be provided on demand to requesting enforcement points.

In any event, in path270, a confirmation can be returned to the key server confirming the installation of the TLS session information including session key in a corresponding enforcement point. Likewise, in path280the key server can provide to the TLS endpoint a confirmation of installation of the TLS session information including session key in one or more enforcement points. Once the TLS endpoint receives confirmation from the key server, in path290a handshake finished message can be returned to the TLS client. Finally, in block300TLS secured data can flow through the enforcement point en route to the TLS endpoint and the enforcement point can decrypt all or only a portion of a traversing data in order to perform one or more functions for the enforcement point before forwarding the TLS secured data flow to the TLS endpoint in path310.