"Insecure Renegotiation" is not about cipher suite selection; it is about a kind of Man-in-the-Middle attack that goes thus:
- Attacker connects to the server and performs a first handshake.
- Attacker pushes some data (e.g. an HTTP POST request).
- Client connects to attacker and sends its initial handshake sequence.
- 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.
- From that point onward, the attacker blindly forwards data back and forth. The server initiates some authentication mechanism with the client.
- 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.)