Bill, that is already good, but then the question still remains of whether there is something that can be done disable/control/detect too many handshakes from any given client (new or renegotiated). I'd love to understand whether this is even a reasonable thing discuss, as I do not have knowledge of the Internals of Apache/OpenSSL.
On Saturday, April 16, 2011, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > 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. > >
