Re: Disabling client initiated renegotiation

[Chris Hill <chris.hillsec@xxxxxxxxx>]

Nothing wrong with re-negotiation if used for what it was intended. Now, since a server cannot limit how many of these a client can request, this leaves the doors open to abuse (DoS --not to be confused with DDoS).

 

To me, disabling it would be as good as limiting how many times a client can request renegotiation.

 

There are actual attacks taking advantage of it, and security vendors (IDS/IPS) are already working on ways to detect these. However, vendors are falling behind when it comes to providing a good solution that can allow system administrators to limit user's trying to take advantage of this.

 

If you are serious about this and want to provide a solution to disable re-negotiation altogether, I would share more info on how this is being exploited.

 

Chris.

On Sat, Apr 9, 2011 at 7:37 PM, Mark Montague <mark@xxxxxxxxxxx> wrote:

 On April 9, 2011 18:00 , Chris Hill <chris.hillsec@xxxxxxxxx>  wrote:

My company relies on Apache for a number of customer facing sites. What's a reliable way to disable client initiated renegotiation (both secure and insecure renegotiation)?. I know one specific openssl library (l) disables this, but then later ones enable "secure" renegotiation, which we need to disable.

Ideally, I'd like a solution through an configuration parameter so that future versions/upgrades do not re-enable renegotiation.

I don't have an answer for you, but, out of curiosity, why do you need to disable SSL 3.0 / TLS renegotiation?  If a client initiates a renegotiation, is this bad in some way?  Obviously, you trusted the client during the initial negotiation/handshake.

--
 Mark Montague
 mark@xxxxxxxxxxx