Skip to content ↓ | Skip to navigation ↓

Earlier this year, it was discovered that under some circumstances the security of an SSL/TLS session between OpenSSL-based systems can be compromised. The attack involves a man-in-the-middle injecting a particular message into the exchange before it would normally be expected. By altering the sequence of messages exchanged during an SSL handshake, the attacker can force the two ends to use insecure keys.

In a proper TLSv1.2 handshake, the client and server exchange random numbers used as input to establish an encryption key. The random values are sent as unencrypted values in the client hello and server hello messages.

To provide privacy on a monitored network, the client then generates another random value (the premaster secret) and encrypts it using the public key from the server’s certificate. The result is transmitted to the server in a client key exchange message.

The random numbers and the premaster secret are used as input to hash algorithms to produce the 48-byte master secret, which is used as an entropy source when generating keys. The security of the protocol is built on the ability to keep anyone else from knowing the master secret.

After the client key exchange, the client will send a change cipher spec signaling the server that future messages will be encrypted using the negotiated cipher and keys to encrypt and authenticate messages. The first encrypted message is always a finished message to confirm that the key exchange process was successful.

The finished message contains a value calculated with the selected cipher’s pseudorandom function (PRF) using the master secret and a hash of the handshake messages. The client and the server send a change cipher spec and finished message and both nodes must verify that the message decrypts properly and contains the expected data.

If either end does not receive what it expects, then the connection must be aborted immediately, otherwise the data channel is expected to be secure.

CVE-2014-0224 describes a problem where OpenSSL will create a master secret without a premaster secret when a change cipher spec is processed before the premaster secret is received/generated. The system is vulnerable because it is willing to compute a master secret without secure data.

A man-in-the-middle can exploit this by sending a spurious change cipher spec message to client and server just after the server hello done message is sent. If the client and server agree on finished message data, the connection will proceed and any messages can be decrypted and even modified by the attacker.

Tripwire’s Vulnerability and Exposure Research Team (VERT) considers OpenSSL versions that do not restrict processing of the early change cipher spec to be affected by CVE-2014-0224. This is consistent with what the OpenSSL team has advised, as well as what other researchers have stated. It is true that a proof of concept has only been developed to demonstrate MITM in some 1.0.1 or later OpenSSL servers but this does not mean that other deployments are not also at risk.

As we have seen repeatedly this year, security bugs can and go unnoticed for many years, making previously ‘impossible’ tasks become possible. Nobody can guarantee that another bug will not be discovered down the road, which can chain together with CVE-2014-0224 allowing MITM.

As Google engineer Adam Langley has demonstrated with the test tool on his blog, an OpenSSL 0.9.8/1.0.0 server will complete a handshake with weak key material if the client sends the expected hash. There are many SSL implementations, including various derivatives of OpenSSL, and it is entirely possible that some of these are broken in a way that would have them calculate the finished message the same way as OpenSSL 0.9.8/1.0.0 servers (This is essentially the behavior demonstrated by Langley’s patch for the Go TLS library).

Many servers disconnect or send a generic error when receiving the early change cipher spec but vulnerable OpenSSL servers process the message. Tripwire IP360 uses this to check for the vulnerability by sending an early change cipher spec after receiving a server hello done. If this does not cause the server to send an error or disconnect, the server has likely calculated a master secret without having a premaster secret (CVE-2014-0224).

If the server is running an affected OpenSSL, there is a strong likelihood that some other component on the system uses that version of OpenSSL as a client and could be attacked with the available proof of concept if it connects to an affected OpenSSL server (update server, etc.). In tests, I found that this technique consistently identified OpenSSL servers within the affected ranges declared by OpenSSL.

Bottom Line

Update servers using OpenSSL before 0.9.8za, 1.0.0m, and especially 1.0.1h as quickly as possible.  In cases where an update is not immediately available, it is best to limit access through private/trusted networks such as LAN or VPN.


Related Articles:


picCheck out Tripwire SecureScan™, a free, cloud-based vulnerability management service  for up to 100 Internet Protocol (IP) addresses on internal networks. This new tool makes vulnerability management easily accessible to small and medium-sized businesses that may not have the resources for enterprise-grade security technology – and it detects the Heartbleed vulnerability.

picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].

Title image courtesy of