Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates
 209.85.214.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=kNH6cpZM237ZlVpH1pJfJ5DTBkzDi+tz5fabNGZA/a29NAapVJrYs6O+e0yIC5q9G+
         jtMUO6PcoIif5gx8CfZdqThFshZmtwxFAFtXN7+yqiCKTsOaCX6xqNZ4Oad2MerDcyNS
         fGyhh8Oq79ZhBHymNYu62kj4VYnjK/W67e2OU=
MIME-Version: 1.0
In-Reply-To: <4DA9F06E.2080908@primary.net>
References: <BANLkTimopHiPHr6pTFgme3Z91x7+3x2uLQ@mail.gmail.com>
	<4DA9F06E.2080908@primary.net>
Date: Sun, 17 Apr 2011 08:41:11 -0400
Message-ID: <BANLkTimW+ZVHw6kM7rEpKhvEcE8bfuZSTQ@mail.gmail.com>
Subject: Re: SSL related DoS
From: Jeff Trawick <trawick@gmail.com>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 16, 2011 at 3:39 PM, Daniel Ruggeri <DRuggeri@primary.net> wrot=
e:
> On 4/16/2011 11:52 AM, Chris Hill wrote:
>>
>> Dear Apache httpd dev list,
>> ...
>> The reason why I insist in this is that the world has come to depend on
>> HTTP/SOAP over SSL (and Apache/OpenSSL are probably the most popular
>> implementation) for business critical apps, yet, it is not clear how
>> these businesses can play around with configuration parameters to fine
>> tune these SSL settings to their specific needs, e.g. *ensure client
>> side renegs can be disabled* or at least,*provide a way of limiting how
>> many of these a client initiated re-negotiations (or initial handshakes)
>> a server will allow per second for a specific connection/IP*. It is
>> great that recent Apache builds disable client initiated renegotiation
>> by default, but how can I ensure this will never be turned back on in
>> future releases given the lack of configuration parameters?
>>
>
> Chris;
> =A0 I believe this topic (enable/disable renegotiation) was brought up on=
 this
> list just a matter of days ago. I don't recall seeing a consensus, but I
> would agree that a configuration parameter to (dis)allow client-initiated
> renegotiation would be a Very Good Thing. I don't think this would be ver=
y
> difficult to implement - and would be a good start to correct the issues =
you
> call out.

I thought client-initiated renegotiation was already disabled out of
the box, with no configuration mechanism to re-enable.

>From ssl_engine_kernel.c, 2.2.x-latest:

    /* If the first handshake is complete, change state to reject any
     * subsequent client-initated renegotiation. */
    else if ((where & SSL_CB_HANDSHAKE_DONE) && scr->reneg_state =3D=3D
RENEG_INIT) {
        scr->reneg_state =3D RENEG_REJECT;
    }