From the perspective of RFC 5746, the DOS and MITM attacks of Renegotiating

 

The ssl dos Vulnerability recently announced by thc is quite popular. In addition to the previous MITM vulnerability, it is estimated that each company will be busy for a while. I have described the MITM vulnerability in Renegotiating TLS Attack. Simply put, it is possible to create a CSRF Attack in any system that uses the lower version of OPENSSL, traffic hijacking-based network-layer attacks that ignore WEB-layer defense are a bit of a three-dimensional "intelligence" attack. Because it is a problem with the TLS protocol, we have developed an extended protocol Renegotiation Indication Extension called secure renegotiation to solve this problem.

 

This new RFC adds three states and a struct to the TLS Protocol, namely the secure_renegotiation flag, client_verify_data, server_verify_data, and renegotiation info struct. The secure_renegotiation flag indicates whether secure re-negotiation is supported. client_verify_data indicates the end data of the last packet in the TLS handshake negotiation sent by the client. TLS indicates 12 bytes and SSL3 indicates 36 bytes. Similarly, server_verify_data is the data sent by the server. When the first negotiation is being established, renegotiated_connection in renegotiation info is set to 0. Client_verify_data must be included when the client requests to start re-negotiation. For a similar server, server_verify_data must be included in the negotiation. The other party checks the data. When using the Renegotiating vulnerability for MITM attacks, the attacker only injects data and cannot decrypt the data. Therefore, this client_verify_data cannot be obtained, leading to failure. Obviously, this new protocol completely solves the MITM problem caused by the Renegotiating vulnerability. Openssl 0.9.8L uses disable Renegotiating. Renegotiating is re-enabled in later versions 0.9.8M, but secure renegotiation is implemented. Note that the mod_ssl configuration of apache retains the option SSLInsecureRenegotiation that is compatible with old customers. Once it is set to on, it is upgraded in white.

 

In addition, the DOS Vulnerability consumes the server's CPU resources in essence. When the encryption algorithm is negotiated, the server CPU overhead is about 15 times that of the client. The Renegotiating mechanism allows attackers to quickly negotiate over a TCP connection. If multiple connections are established, the pressure on the server is even more terrible, and the number of such attacks is rarely noticeable. THC declared that the attack cannot be avoided even if the Renegotiating function is disabled. Yes, even if the function is disabled, a connection can still be attacked in a way similar to connection flood. A connection performs negotiating instead of Renegotiating. Of course, this is already a relief, because in this case, the attacker's overhead increases and the number of connections on the server is more easily monitored. Some may say that you don't need to disable Renegotiating. You only need to Upgrade openssl and apache to solve the problem, but this is just an illusion, because the outgoing code does not implement secure renegotiation, if there is a problem, how can this problem be solved?

 

In fact, the current defense scheme is a shield with a piece of paper.

 

From Xinlu