Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4DA6C12D.2020408@rowe-clan.net>
Date: Thu, 14 Apr 2011 04:41:01 -0500
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Fwd: Client Initiated Renegotiation after 0.9.8l
References: <4DA6B6FC.7010704@rowe-clan.net>
 <20110414092834.GA5142@redhat.com>
In-Reply-To: <20110414092834.GA5142@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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 ;-)