4

On one server, we have removed weak cipher suites and insecure protocols to try to pass SSLScan / SSL Labs. One outstanding problem is Insecure Renegotiation. I read that:

The Apache Software Foundation has reported an issue that may occur when the SSLCipherSuite directive is used to upgrade a cipher suite. Particular sequences of per-directory renegotiations may cause a weaker cipher suite being used in place of the upgraded one.

If this issue were to occur, flaws in weaker ciphersuites could be exposed. This could threaten the integrity of SSL transactions negotiated between a vulnerable server and the client. This could provide an opportunity for passive attackers in a position to observe such a transaction.

My question is if we have removed the weak cipher suites, is it not true that there are no weak cipher suites left to renegotiate to and this becomes a non-issue (except that the grade is still an F and that looks bad)?

  • Can you give us more information? Perhaps a copy-and-paste of the problem(s) that the scans found? – Neil Smithline Jan 27 '16 at 1:26
  • "Insecure session renegotiation supported" was the only problem reported – mcgyver5 Jan 27 '16 at 2:13
  • If I remember correctly, the triple handshake attack is enabled by renegotiation. If you didn't already do that, read about mitigation strategies against that attack – Michael Karcher Jan 27 '16 at 7:49
  • 1
    Insecure renegotiation allows for arbitrary data injection: blog.ivanristic.com/2009/11/… – Michael Jan 27 '16 at 15:46
6

"Insecure Renegotiation" is not about cipher suite selection; it is about a kind of Man-in-the-Middle attack that goes thus:

  1. Attacker connects to the server and performs a first handshake.
  2. Attacker pushes some data (e.g. an HTTP POST request).
  3. Client connects to attacker and sends its initial handshake sequence.
  4. Attacker forwards the client handshake messages to the server and back. From the point of view of the client, this is the initial handshake; from the point of view of the server, this is a renegotiation within the context established initially with the attacker.
  5. From that point onward, the attacker blindly forwards data back and forth. The server initiates some authentication mechanism with the client.
  6. The server erroneously considers that the authentication result covers the complete dialogue, including the data that the attacker pushed before the renegotiation. As a result, the server may apply the attacker's request as if it came from the authenticated client.

RFC 5746 is a mechanism (a TLS extension) that aims at making initial handshake and renegotiation handshake distinct. If supported by both client and server, then the server, in the scenario above, will notice that the ClientHello in the second handshake is tagged as "initial", not as "renegotiation", and will thus reject the attempt. When some report tells you that your server does "insecure renegotiation", it really tells you that your server does not support RFC 5746. This is completely unrelated to cipher suite selection, and there is no change in your list of cipher suites that will do anything for or against that; this is an orthogonal setting.

One may note that allowing insecure renegotiation does not necessarily imply an exploitable hole. It really depends on how the server handles user authentication, in particular with regards to renegotiations. Conceptually, a server who receives an unauthenticated request may initiate a renegotiation (e.g. with certificate-based client authentication) and then, after the second handshake, send an HTTP redirect so that the client sends the request again. In such a case, there would not be any problem with lack of support of RFC 5746. However, existing Web servers do not operate that way, hence a common need to "strengthen" renegotiations systematically at the TLS level.

(In general terms, the problem with renegotiations is that SSL/TLS provides security only in the chronologically forward direction, while users of SSL/TLS, i.e. Web server, commonly assume that security extends backwards as well, even across renegotiations. RFC 5746 fixes a known, explicit attack modality, but it is unclear -- or at least undocumented -- whether it really ensures backward-facing authentication up to the initial handshake.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.