httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r906039 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c ssl_engine_config.c ssl_engine_init.c ssl_engine_kernel.c ssl_private.h
Date Wed, 03 Feb 2010 22:23:49 GMT
On Wed, Feb 03, 2010 at 03:33:23PM -0600, William Rowe wrote:
> On 2/3/2010 3:18 PM, Joe Orton wrote:
> > On Wed, Feb 03, 2010 at 12:44:45PM -0500, Eric Covener wrote:
> >> On Wed, Feb 3, 2010 at 12:09 PM, Joe Orton <jorton@redhat.com> wrote:
> >>> I considered logging a warning for each client which renegotiates
> >>> insecurely (whether due to lack of support on client or server), but,
> >>> that's likely to be very noisy.
...
> How would this work if the renegotiation occurred after the request
> was actually sent?  [And of course, once the MITM is injected, you have
> no trust of the chain of authority].

Sorry, that's really sloppy wording on my part above.  The information 
we want to log here is the single bit of data:

"does the client support the secure reneg protocol: yes/no"

New clients will advertise support for the secure reneg protocol in the 
initial handshake of any SSL connection.  Old clients, and any attacker 
trying to perform the MITM, will not.  All renegs on the connection will 
either be secure for new clients, or, if now permitted by config, 
insecure for old clients/attackers.

So with my patch, if you log %{ssl-secure-reneg}n it will be invariant 
for all the requests on any given SSL connection, and orthogonal to 
whether any reneg actually takes place on that connection.  It's just 
reporting the client's capability, rather than indicating any particular 
reneg is secure/insecure.

Does this make sense?

Regards, Joe

Mime
View raw message