Mailing List Archive: Apache: Dev

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

Index | Next | Previous | View Threaded

poirier at pobox

Feb 3, 2010, 8:51 AM

Post #1 of 7 (1636 views)
Permalink

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

How about logging a dire warning during startup if insecure
renegotiation has been enabled?

Dan

jorton at redhat

Feb 3, 2010, 9:09 AM

Post #2 of 7 (1553 views)
Permalink

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 [In reply to]

On Wed, Feb 03, 2010 at 11:51:16AM -0500, Dan Poirier wrote:
> How about logging a dire warning during startup if insecure
> renegotiation has been enabled?

Hmmm, I'm not sure. If the user has configured this it seems slightly
patronising to then berate them for doing so. Also, why log in the case
that the directive is supported and enabled, but not the case where the
directive is unsupported because OpenSSL is too old? In either case
reneg is (or may be) insecure.

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.

Regards, Joe

covener at gmail

Feb 3, 2010, 9:44 AM

Post #3 of 7 (1558 views)
Permalink

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 [In reply to]

On Wed, Feb 3, 2010 at 12:09 PM, Joe Orton <jorton [at] redhat> 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.

Any way to note the insecure renegotiation and save it long enough to
be associated with a r->notes or subprocess_env?

That would let you log it with IP and user-agent in access log (and
help you convince yourself it might be safe to turn on strict
renegotiation based on log analysis)

--
Eric Covener
covener [at] gmail

jorton at redhat

Feb 3, 2010, 1:18 PM

Post #4 of 7 (1542 views)
Permalink

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 [In reply to]

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 [at] redhat> 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.
>
> Any way to note the insecure renegotiation and save it long enough to
> be associated with a r->notes or subprocess_env?
>
> That would let you log it with IP and user-agent in access log (and
> help you convince yourself it might be safe to turn on strict
> renegotiation based on log analysis)

Nice idea, yes, that seems sensible. This seems to work:

Index: ssl_engine_kernel.c
===================================================================
--- ssl_engine_kernel.c (revision 906057)
+++ ssl_engine_kernel.c (working copy)
@@ -242,6 +242,15 @@ int ssl_hook_ReadReq(request_rec *r)
ssl_util_vhostid(r->pool, r->server));
}

+ apr_table_setn(r->notes, "ssl-secure-reneg",
+#ifdef SSL_get_secure_renegotiation_support
+ SSL_get_secure_renegotiation_support(ssl)
+ ? "1" : "0"
+#else
+ "0"
+#endif
+ );
+
/* SetEnvIf ssl-*-shutdown flags can only be per-server,
* so they won't change across keepalive requests
*/

wrowe at rowe-clan

Feb 3, 2010, 1:33 PM

Post #5 of 7 (1546 views)
Permalink

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 [In reply to]

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 [at] redhat> 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.
>>
>> Any way to note the insecure renegotiation and save it long enough to
>> be associated with a r->notes or subprocess_env?
>>
>> That would let you log it with IP and user-agent in access log (and
>> help you convince yourself it might be safe to turn on strict
>> renegotiation based on log analysis)
>
> Nice idea, yes, that seems sensible. This seems to work:

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].

I can see a value in allow-from {trusted IP pool}. But not sure this
really helps, since it doesn't limit the renegotiation, it limits the
request acceptance.

jorton at redhat

Feb 3, 2010, 2:23 PM

Post #6 of 7 (1543 views)
Permalink

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 [In reply to]

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 [at] redhat> 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

wrowe at rowe-clan

Feb 3, 2010, 4:16 PM

Post #7 of 7 (1542 views)
Permalink

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 [In reply to]

On 2/3/2010 4:23 PM, Joe Orton wrote:
>
> Does this make sense?

Much more - thanks for the explanation!

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads