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 <[email protected]> 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
