Last week, news arrived about a new vulnerability in OpenSSL, which affected all releases of the library. This new vulnerability, frequently referred to as the CCS vulnerability, is a Man In the Middle (MITM) vulnerability, allowing an attacker to listen in on, or modify data on a connection by tricking the client and server to set up their connection using predictable encryption keys.
The CCS problem
The way this works is that an attacker who is able to intercept and modify the traffic between the client and the server injects specific TLS protocol messages, the Change Cipher Spec (CCS) message, into the connection stream earlier than either party would expect them to be received. The CCS message, which is not part of the handshake messages, indicates to the recipient that all successive TLS Protocol records received from the sender are encrypted with the recently calculated encryption keys.
This message is intended to be sent after the parties have exchanged sufficient information to calculate those keys. Unfortunately, it turns out that OpenSSL (in both client and server mode) did not check that those milestones had been passed before accepting the signal and proceeding to calculate the encryption keys without the benefit of the random secret sent by the client. The result is that the parties starts to encrypt the handshake using predictable encryption keys, allowing the attacker to decrypt and/or modify the transmitted data.
Could this vulnerability have been prevented?
The main reason why this problem developed was that OpenSSL’s implementation of its handling of the the CCS message did not check if the message was expected at that particular time. Instead it just took the expected actions, calculating the encryption keys and enabling them. Better checks of the sequence and preconditions would likely have prevented the issue.
Looking beyond implementation errors, this problem is actually in the same category as the Renego issue (as well as the recent, Renego-related Triple handshake problem): it became possible because the TLS methods used to verify handshake integrity did not include all relevant information necessary to ensure the integrity of the connection.
In this case, my opinion is that a minor change to the design of the TLS protocol itself might have helped prevent the CCS problem. As mentioned above, the CCS message is not part of the handshake protocol, for reasons having to do with improving the flow of the protocol. The CCS not being a member of the handshake messages (but still an important part of the handshake sequence) means that it is not included in the calculation of the handshake integrity, which is used to ensure that the client and the server agree that they sent and received all the handshake messages, and that there have been no changes made to those messages while they were in transit. The result is that CCS messages can be added and removed by an attacker without it being detected unless the parties are coded to assume they arrive when they are expected.
The change that I think would have prevented this problem (as far as injection attacks are concerned, at least) is to include the CCS in the data used to check the integrity of the handshake. If this had been done, then the extra CCS messages used by the attacker in this case would change the integrity check, and the client and server would be unable to send the correct values to the server because they would have been seeing different handshake and CCS message sequences, and would have terminated the connection due to the mismatch, thus eliminating the vulnerability.
Affected products
It is definitely known that this attack will work with any version of OpenSSL based clients when they connect to a vulnerable OpenSSL 1.0.1 (pre-1.0.1h) based server. It is presently unknown if OpenSSL clients connecting to servers using older vulnerable versions of OpenSSL (pre-0.9.8za or pre-1.0.0m) are vulnerable to the attack, this is due to changes in some of the calculations in the 1.0.1 version made it easier to attack.
OpenSSL clients are extensively used in Android based devices for both the native browser and by apps, so these devices should be updated. Additionally, Konqueror based browsers on Linux/KDE are as far as I know using OpenSSL for TLS support. The OpenSSL TLS stack may also be used (especially on Linux, but also other platforms) by servers and clients for, at least, email, chat, authentication and SSL-based VPN, as well as various scripts in Python or other scripting languages. Users of such software should upgrade as soon as patches become available.
Clients not based on OpenSSL’s stack are not vulnerable (this includes Opera 12, which only uses OpenSSL for the crypto primitives, not the TLS protocol, as it is using its own TLS implementation).
Mitigating factor
This vulnerability requires that both the client and server is vulnerable to the problem. This means that for a user to avoid being vulnerable, the user only needs to make sure he or she only use clients or versions of clients that are not vulnerable.
Severity
Severity-wise this vulnerability isn’t quite as bad as Heartbleed, but I would rate it as more severe than the Renego issue. Heartbleed allowed exposure of private data by the server, including the private key, while the Renego issue “only” allowed injection of requests and data into the beginning of a connection. This issue allows the attacker to take over a connection, and it is thus more severe than prefix data injection, but less severe than a server-side data leak that can expose private keys or data on users whose connections have not been intercepted.
Number of affected servers
Using the available information, in particular information and examples from Google’s Adam Langley, I added a new test for my TLS Prober scanner, and ran a scan of my normal group of 540000 servers to discover how many servers are affected by this problem.
According to these data, obtained a week after the disclosure, 17.3% of the scanned servers are definitely vulnerable, as they are using vulnerable OpenSSL 1.0.1 installations, while a further 37.8% are using vulnerable OpenSSL 1.0.0 versions or older and are thus possibly vulnerable (assuming a workable attack can be created), indicating that about 55% of the sampled servers are affected, and should be patched
It will be interesting to see how quickly this issue gets patched in the coming weeks and months.
Vivaldi.net status
With respect to Vivaldi.net’s own servers, which are using Apache and OpenSSL for TLS, they were patched shortly after patches became available, and are no longer affected by the problem.
thank your bài viêt hay