The vulnerability of transport or application layer security protocols, such as protocols operating at the application layer of the internet protocol suite, is widely recognized with the extent of the vulnerability becoming increasingly apparent on detection of the Transport Layer Security (TLS)/Secure Sockets Layer (SSL) “Heartbeat” exploit.
The Heartbeat exploit takes advantage of a vulnerability in an open source implementation of SSL known as OpenSSL, specifically OpenSSL version 1.0.1 and version 1.0.2 beta. The vulnerability arises due to an incorrect implementation of an extension to the SSL protocol known as the “heartbeat extension” defined in RFC6520 (Seggelmann et al., Internet Engineering Task Force (IETF), February 2012). According to the heartbeat extension, “heartbeat” packets can be exchanged between a client and a server communicating via an encrypted connection in order to keep the encrypted connection alive, for example in the absence of substantive packet communication. A client transmits a “heartbeat request” packet to the server with a payload and a payload length field. The server responds with a “heartbeat response” including the payload of the heartbeat request. In this way the server knows to maintain the secure connection (lost secure connections are resource expensive to replace) while the client confirms that the server received the heartbeat request by identity of the payload in the response and request messages. The heartbeat process is defined to include the payload in order that it can be applied to datagram transport protocols such as Datagram Transport Layer Security (DTLS) over User Datagram Protocol (UDP).
Certain versions of OpenSSL incorrectly implement the protocol by permitting a mismatch between a length, in bytes, of a payload in a heartbeat request packet and a stated length in a payload length field of the request packet. Heartbeat request packets with very short (e.g. 1 byte) payloads but with large (e.g. a maximum 64 kilobytes) stated lengths are not detected by the server. In response to such requests the server provides a heartbeat response with a payload of length matching the stated length in the request, irrespective of the actual length of the request payload. Thus, where a server responds with a payload longer than the actual payload received in a heartbeat request message, the server transmits a portion of a memory of the server (a “memory dump”) extending beyond the portion containing the payload bytes received in the heartbeat request. This constitutes a type of memory overrun and can include sensitive data such as encryption key, encryption algorithm, encryption version or certificate information employed for the secure communication. In this way, a malicious or tampered client or a malicious interceptor can gain sensitive, secret or secure data from the server. Such data can be used to monitor a secure communication such as by decrypting the communication or masquerading as the client or server, etc.
Fixes and patches for such software defects exhibiting security vulnerabilities can be developed and made available very soon after identification of issues. However, such fixes involve the installation of replacement secure protocol libraries such as SSL libraries. Such installation can require restarting, rebooting, refreshing or relinking communication software or any software involving any communication function. Secure network communication is increasingly endemic to software worldwide, whether consumer web browsers for network services or transactions or large financial institutions such as banks engaged in large numbers of transactions 24 hours a day. Restarting such software can be extremely expensive and the cost of remediating a security vulnerability is substantially measured in terms of lost availability of such services during application of a remediation.
Thus, it would be advantageous to provide for swift and ready remediation of known security protocol vulnerabilities without the aforementioned disadvantages.