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 <m...@catseye.org> wrote: > On April 9, 2011 18:00 , Chris Hill <chris.hill...@gmail.com> 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 > m...@catseye.org > >
