On 4/14/2011 9:10 AM, Joe Orton wrote: > On Thu, Apr 14, 2011 at 04:41:01AM -0500, William Rowe wrote: >> It seems like our directive is a serious misnomer, if it is required to >> enable either legacy or new renegotiation. Before 2.2.18, it seems >> prudent to make this a tristate (legacy or modern, modern only, or none) >> and support it again, even if the default is a safe 'none' value. > > I think you're mixing the two separate (and technically orthogonal) > questions: > > a) whether or not to allow insecure renegotiation > b) whether or not to allow client-initiated reneg
Ah, interesting. I hadn't considered (a) in light of server-initiated renegotiation only. It would seem that 'SSLInsecureRenegotiation on' might deserve a companion SSLPeerRenegotiation on|insecure|off (default value off) setting if we have any desire to restore client renegotiation at all. And of course, there's always SSLProxyRenegotation, where we are playing the client (and may have new and legacy servers behind us)? Wondering what we might want to do, there?
