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 Message -------- Subject: Client Initiated Renegotiation after 0.9.8l Date: Wed, 13 Apr 2011 18:42:45 -0400 From: Chris Hill <[email protected]> Reply-To: [email protected] To: [email protected] Open SSL dev team, It seems like in releases after OpenSSL 0.9.8l (the ones that contained the fix for cve 2009-3555), client initiated "secure/safe" renegotiationw was never re-enabled by default, judging by how Apache behaves. In short, prior to 0.9.8l, you could do something as simple as "openssl s_client -connect host:443", then assuming it was HTTP, you could do "HEAD / HTTP/1.1" followed by an "R", and renegotiation would take place (in this case insecure). However, after the "l", at least judging for how apache behaves, from a client that supports secure renegotiation, when this same thing is attempted, the below happens. GET / HTTP/1.0 R RENEGOTIATING 140716401080128:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:590: $ Q1) Is this enough for me to assume client initiated renegotiation is NOT enabled by default after 0.9.8l? (By this I mean both secure and insecure but only when initiated by the client, NOT the server). Q2) Assuming the above is confirmed, is there any plans to re-enable client initiated renegotiation by default in future releases? I am hoping for this answer to be NO. Thanks, Chris.
