Fwd: Client Initiated Renegotiation after 0.9.8l

["William A. Rowe Jr." <wr...@rowe-clan.net>]

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 <ch...@gmail.com>
Reply-To: 	openssl-dev@openssl.org
To: 	openssl-dev@openssl.org



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.

Re: Fwd: Client Initiated Renegotiation after 0.9.8l

["William A. Rowe Jr." <wr...@rowe-clan.net>]

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?

Re: Fwd: Client Initiated Renegotiation after 0.9.8l

[Joe Orton <jo...@redhat.com>]

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

The directive controls (a), and (b) is hard-coded to "not allowed".  If 
there is evidence that the default setting for (b) is wrong let's hear 
the arguments, and consider whether a default of "allowed" is instead 
appropriate, rather than jumping to add another config option?

Re: your other point, on performance impact of client-initiated reneg, I 
agree with you; others in that thread argue that there there is a kind 
of "unanticipated" CPU overhead of reneg which may not be accounted for 
in traditional load/bandwidth/connection-limiting or balancing 
techniques.  

e.g. MaxKeepAliveRequests to some degree bounds resource usage per TCP 
connection at HTTP level; there's no equivalent to bound CPU usage due 
to renegs.  I'm not sure this is a particularly solid argument though.

Regards, Joe

Re: Fwd: Client Initiated Renegotiation after 0.9.8l

["William A. Rowe Jr." <wr...@rowe-clan.net>]

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 
> reneg, so why should mod_ssl disable it?  I don't find that terribly 
> compelling; reneg and HTTP over SSL is a conceptual mess, and a 
> significant proportion of the security issues in mod_ssl have been 
> reneg-related (though maybe that sounds FUDdish).

As another data point, Tomcat https connector never really supported
renegotiation until the eve of CVE 2009-3555, IIRC (talk about timing ;-)

Thanks for the thread pointer.

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.

Of course the very advisability of unilaterally trusting CAs has been
in question for some time now, so to suggest we are protecting users
by disabling any renegotiation seems like a small worry ;-)

Re: Fwd: Client Initiated Renegotiation after 0.9.8l

["William A. Rowe Jr." <wr...@rowe-clan.net>]

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, vs perpetually
refreshing the session on the same connection.  If I'm mistaken, I'd
love to learn how.

Re: Fwd: Client Initiated Renegotiation after 0.9.8l

[Joe Orton <jo...@redhat.com>]

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 been relaxed.  It would be simple to 
change the code to allow client-initiated reneg iff secure reneg is 
supported by both sides.

There was a discussion on this topic recently at the IETF TLS list:

http://thread.gmane.org/gmane.ietf.tls/8335/focus=8358

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 
reneg, so why should mod_ssl disable it?  I don't find that terribly 
compelling; reneg and HTTP over SSL is a conceptual mess, and a 
significant proportion of the security issues in mod_ssl have been 
reneg-related (though maybe that sounds FUDdish).

So I tend towards "less renegotiation is good"; very interested to hear 
other opinions.

Regards, Joe