Rainer,
as you've done more work on this than anyone, in terms of the mod_ssl handling
of renegotiation, can you shed some light on this?
Looking at current 2.2.17 httpd with openssl 0.9.8o, and using 0.9.8o to attempt
to 'R'enegotiate, the report appears accurate.
Bill
Original
On Thu, Apr 14, 2011 at 03:57:32AM -0500, William Rowe wrote:
Looking at current 2.2.17 httpd with openssl 0.9.8o, and using 0.9.8o to
attempt
to 'R'enegotiate, the report appears accurate.
Yup, it's a legacy of the patch for CVE-2009-3555; the prevention of
client-initiated reneg has never
On 4/14/2011 4:28 AM, Joe Orton wrote:
If it's true that IIS also rejects client-initiated reneg (per claim in
that thread), I'd say there is no imperative to change mod_ssl's
behaviour from an interop perspective.
You can argue for correctness; the protocol allows a client-initiated
On 4/14/2011 4:28 AM, Joe Orton wrote:
There was a discussion on this topic recently at the IETF TLS list:
http://thread.gmane.org/gmane.ietf.tls/8335/focus=8358
Just FWIW, I didn't see a distinction between connecting/establishing
new unique sessions then disconnecting, rinse and repeat,
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
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,
