On 4/16/2011 2:39 PM, Daniel Ruggeri wrote: > On 4/16/2011 11:52 AM, Chris Hill wrote: >> but how can I ensure this will never be turned back on in >> future releases given the lack of configuration parameters? > > Chris; > I believe this topic (enable/disable renegotiation) was brought up on this > list just a > matter of days ago. I don't recall seeing a consensus, but I would agree that > a > configuration parameter to (dis)allow client-initiated renegotiation would be > a Very Good > Thing. I don't think this would be very difficult to implement - and would be > a good start > to correct the issues you call out.
One, there are no assurances. But today, renegotiation will not work out of the box *without* SSLInsecureRenegotation... The group consensus seems to be that introducing 'new' safe client renegotiation will come at the cost of a new directive to -enable- it, leaving it disabled, by default. The group seems to generally doubt that there is any DoS (SSL is resource intensive, new connections and renegotiated connections are equally so), but there doesn't seem to be any immediate demand for renegotiation support, so it makes the most sense to leave it optional-to-enable rather than optional-to-disable.
