OpenSSL CCS Vulnerability

Yngve Pettersen continues to study vulnerability issues and test web servers to address open-loop issues.

Last week, there were reports of a new vulnerability in OpenSSL , to which all versions of the library were exposed. This new vulnerability, often called the CCS vulnerability, is of type MITM (Man In The Middle) and allows an attacker to “listen in” or change the data sent between the client and the server, deceiving both sides — the client and the server — to establish a connection between them using predictable encryption keys.

CCS problem

')
The vulnerability is exploited as follows: an attacker, having the ability to connect and control traffic between the client and the server, injects certain TLS protocol messages (in particular, Change Cipher Spec (CCS) messages) into the data stream earlier than any of the parties would expect to receive them. The CCS message, which is not part of the handshaking messages, indicates to the recipient that all consecutive TLS Protocol entries received from the sender are encrypted with the newly created encryption keys.

This message is intended to be sent after the parties have exchanged enough information to create encryption keys. Unfortunately, it turned out that OpenSSL (both on the client side and the server side) does not check whether all the procedures have been completed and the confirmation signal has been received, and continues to create encryption keys without using the secret key sent by the client. As a result, the parties begin to handshake using predictable encryption keys, allowing the attacker to decrypt and / or modify the transmitted data.

Could this vulnerability be avoided?

The main reason for this problem is that when processing CCS messages in OpenSSL, it was not checked whether the message arrived at the time it was expected. Instead, the usual steps were taken to create and use encryption keys. Perhaps a more thorough check of the sequence of actions and the compliance of the required conditions could prevent the problem.

If you do not take into account implementation errors, then this problem falls into the same category as Renego (and the recent Renego triple-handshake problem ): the vulnerability was possible because the TLS methods used to verify the reliability of the handshake did not include all the necessary information guaranteeing the reliability of the connection.

In this case, in my opinion, there were enough minor changes in the implementation of the TLS protocol to prevent the CCS problem. As I said above, the CCS message is not part of the handshake protocol for performance reasons. CCS does not refer to handshaking messages (although it is an important part of the handshaking process), therefore it is not included in the handshake integrity verification process, which is designed to ensure that the client and server sent and received all handshaking messages and that no changes were made to these messages. during their shipment. As a result, CCS messages can be added and deleted by an attacker without the threat of being detected if the parties do not control the time of receipt of messages.

I assume that the problem could have been prevented by including CCS in the data used to verify the integrity of the handshake. If this were done, the additional CCS messages used in this case by the attackers would violate the integrity check, and the client and server would be unable to send the correct values ​​to each other, because they would see different acknowledgment and CCS sequences, and then break connection due to inconsistencies, thus eliminating the vulnerability.

Affected Products

It is already known that this attack will work with any version of clients using OpenSSL if they connect to a vulnerable server using OpenSSL 1.0.1 (pre-1.0.1h). It is not yet known whether OpenSSL clients connecting to servers using older versions of OpenSSL (pre-0.9.8za or pre-1.0.0m) are at risk, since in fact the breach for the attacks was created in versions 1.0.1 due to simplification of some verification procedures.

OpenSSL clients are extensively used in Android devices, both by the built-in browser and by applications, so the software of these devices must be updated. In addition, Konqueror-based browsers that are popular on Linux / KDE also use OpenSSL to support TLS, if my memory serves me. The OpenSSL TLS stack can also be used (especially on Linux, but also other platforms) servers and clients, at least for email, chat, authorization, and SSL-based VPNs, as well as in various scripts written using Python or other languages. Users must update this software as soon as patches become available.

Non-OpenSSL stack-based clients are not vulnerable (including Opera 12, which uses OpenSSL only for crypto primitives, and uses its own implementation of TLS).

Mitigating factor

This vulnerability requires that both the client and the server are vulnerable. Thus, a user who wants to avoid a problem should only make sure that he is using clients or versions of clients that are not affected by this vulnerability.

How dangerous is this vulnerability?

It can be said that this vulnerability is not as dangerous as Heartbleed , but I would rate it as more serious than the problem of Renego . Heartbleed opened access to private data on the server, including the private key, while Renego allowed “only” to inject queries and data at the beginning of the connection. A new problem allows an attacker to connect to the connection, and thus this vulnerability is more serious than prior data injection, but less serious than data leakage from the server, which could give attackers a private key or user data whose connections were not interrupted.

Number of affected servers

Using the available information and, in particular, information and examples from Adam Langley , working at Google, I added a new test for my TLS Tester scanner and scanned my regular experimental group of 540,000 servers to find out how many servers were affected by this problem.

According to the data I received a week after the vulnerability was revealed, 17.3% of the scanned servers were definitely vulnerable because they use vulnerable versions of OpenSSL 1.0.1, while another 37.8% use vulnerable versions of OpenSSL version 1.0.0 or earlier and, thus theoretically vulnerable. In total, approximately 55% of the selected servers are unreliable and should be fixed.

It will be interesting to see how quickly this problem will be fixed in the coming weeks and months.

The situation with Vivaldi.net

Speaking of Vivaldi.net 's own servers that use Apache and OpenSSL for TLS, it should be noted that they were fixed soon after the patches became available and are not affected by the problem at the moment.

From translator
In fact, the topic for me is not very close, so there are certainly some inconsistencies in terminology in the translation. I invite everyone interested to read the original article .