Re: [RFC] JSON logging support for httpd 2.4.x

[Thomas Meyer]

Hi,

How to proceed with #373, can someone please give some feedback?

Mfg
Thomas

Am 8. September 2023 20:35:09 MESZ schrieb Thomas Meyer :
>Hi,
>
>as I learned all code must go to trunk first, so I kindly ask to review my 
>updated patch against trunk here:
>
>https://github.com/apache/httpd/pull/373
>
>Once this pr is reviewed and merged I'm going to retrofit pr353 against 2.4.x
>
>with kind regards 
>thomas
>
>Am 31. März 2023 09:04:35 MESZ schrieb Thomas Meyer :
>>Hi,
>>
>>Sadly I got no feedback at all.
>>
>>What is the preferred way for contributions?
>>
>>I also did raise a PR here with some fixes on top of this patch series:
>>
>>https://github.com/apache/httpd/pull/353
>>
>>Mfg
>>Thomas
>>
>>Am 24. März 2023 22:54:08 MEZ schrieb Thomas Meyer :
>>>
>>>Hi,
>>>
>>>please have a look at this preliminarily work to support JSON output in 
>>>mod_log_config.
>>>
>>>It's still unfinished and has probably a lot of bugs, but this is to show 
>>>the general idea
>>>of my solution.
>>>
>>>Help and feedback is most welcome.
>>>
>>>Mfg
>>>thomas
>>>
>>>
>>
>>-- 
>>Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>-- 
>Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: [RFC] JSON logging support for httpd 2.4.x

[Thomas Meyer]

Hi,

as I learned all code must go to trunk first, so I kindly ask to review my 
updated patch against trunk here:

https://github.com/apache/httpd/pull/373

Once this pr is reviewed and merged I'm going to retrofit pr353 against 2.4.x

with kind regards 
thomas

Am 31. März 2023 09:04:35 MESZ schrieb Thomas Meyer :
>Hi,
>
>Sadly I got no feedback at all.
>
>What is the preferred way for contributions?
>
>I also did raise a PR here with some fixes on top of this patch series:
>
>https://github.com/apache/httpd/pull/353
>
>Mfg
>Thomas
>
>Am 24. März 2023 22:54:08 MEZ schrieb Thomas Meyer :
>>
>>Hi,
>>
>>please have a look at this preliminarily work to support JSON output in 
>>mod_log_config.
>>
>>It's still unfinished and has probably a lot of bugs, but this is to show the 
>>general idea
>>of my solution.
>>
>>Help and feedback is most welcome.
>>
>>Mfg
>>thomas
>>
>>
>
>-- 
>Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: [RFC] JSON logging support for httpd 2.4.x

[Christophe JAILLET]

Le 31/03/2023 à 09:04, Thomas Meyer a écrit :

Hi,

Sadly I got no feedback at all.

What is the preferred way for contributions?


Hi,

mailing list is fine.
You can also use github if it is easier for you.



I also did raise a PR here with some fixes on top of this patch series:

https://github.com/apache/httpd/pull/353 



Mfg
Thomas

Am 24. März 2023 22:54:08 MEZ schrieb Thomas Meyer :


Hi,

please have a look at this preliminarily work to support JSON output in 
mod_log_config.

It's still unfinished and has probably a lot of bugs, but this is to show 
the general idea
of my solution.

Help and feedback is most welcome.

Mfg
thomas


--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


As you have already notices, there is already a mod_log_json in trunk 
(see [1])


AFAIK, it is not documented.

Have you looked at it first?
Does it match your needs?

There is also an old WiP related to make ErrorLog logging modular.
I've not looked at it since a LNG time. But do you think it would help?


CJ


[1]: 
https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/loggers/mod_log_json.c?view=markup=date


[2]: 
http://people.apache.org/~jkaluza/patches/httpd-2.4.x-errorlog_provider.patch

Re: [RFC] JSON logging support for httpd 2.4.x

[Thomas Meyer]

Hi,

Sadly I got no feedback at all.

What is the preferred way for contributions?

I also did raise a PR here with some fixes on top of this patch series:

https://github.com/apache/httpd/pull/353

Mfg
Thomas

Am 24. März 2023 22:54:08 MEZ schrieb Thomas Meyer :
>
>Hi,
>
>please have a look at this preliminarily work to support JSON output in 
>mod_log_config.
>
>It's still unfinished and has probably a lot of bugs, but this is to show the 
>general idea
>of my solution.
>
>Help and feedback is most welcome.
>
>Mfg
>thomas
>
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[RFC] JSON logging support for httpd 2.4.x

[Thomas Meyer]

Hi,

please have a look at this preliminarily work to support JSON output in 
mod_log_config.

It's still unfinished and has probably a lot of bugs, but this is to show the 
general idea
of my solution.

Help and feedback is most welcome.

Mfg
thomas

Re: RFC: Documenting changes in the CHANGES file

[Ruediger Pluem]

On 6/8/20 10:20 AM, Ruediger Pluem wrote:
> 

>>
> 
> Thanks for all the feedback. I try to work out something more detailed aka 
> patch that we can discuss then.
> 

Done as r1879822. Happy to get some feedback.

Regards

Rüdiger

Re: RFC: Documenting changes in the CHANGES file

[Nick Kew]

> On 1 Jun 2020, at 13:33, Graham Leggett  wrote:
> 
> On 29 May 2020, at 21:30, Ruediger Pluem  wrote:
> 
>>  changes-fragments/
>>2.4.41/
>>2.4.42/
>>2.4.43/
>>2.4.44/

And a current/ as symlink?

> I’m keen for a simpler version of this that doesn't create additional steps 
> for people.

Not sure that's simpler, though it too has potential.  Delete-after-append 
seems tidier
than keeping forever-fragments.

I wonder if this could be hooked into SVN?  Something like an @CHANGES tag in
a svn commit message?

-- 
Nick Kew

Re: RFC: Documenting changes in the CHANGES file

[Ruediger Pluem]

On 6/2/20 2:17 PM, Stefan Eissing wrote:
> 
>> Am 02.06.2020 um 14:11 schrieb Daniel Ruggeri :
>>
>> On 6/1/2020 6:23 AM, Yann Ylavic wrote:
>>> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem 
>>>  wrote:
>>>
 Reviewing our backport process I noticed that in many cases a clean merge 
 via svn merge fails due to conflicts in CHANGES. While
 these are easy to solve it puts IMHO unnecessary extra work on the 
 backport process, both for reviewing and for actually doing the
 backport. How about if we change the way we document changes the following 
 way:

 1. We create a changes-fragments directory (name to be determined) at the 
 top level.
 2. For each release we create a subdirectory such that we end up with the 
 following structure:

changes-fragments/
  2.4.41/
  2.4.42/
  2.4.43/
  2.4.44/

 3. Each directory contains the changes for each release and each change 
 entry is a single file.
 4. We have a script that builds our current CHANGES file from the content 
 in changes-fragments directories with the help of
a template or at least some sort of header / footer that is static.
 5. This script can be called either manually and we commit the resulting 
 CHANGES file as we like just like the x-forms commits
for documentation plus this script is called by the release scripts 
 from Daniel as part of the preparation of rolling a
release.

>>> +1 from me, I don't volonteer for the scripts though :)
>>>
>>> Regards;
>>> Yann.
>>>
>> Hi, Yann;
>>
>> I'm open to whatever... and don't mind writing or tweaking scripts once we 
>> decide on an approach :-)
>>
>> While we are discussing ideas in this neighborhood, one thing to keep in 
>> mind is that during release of security fixes, sometimes there are items 
>> added to CHANGES and sometimes CHANGES is modified to add CVE information. 
>> There have been minor bumps in the road where these patches don't always 
>> apply cleanly. So, if possible, it would be great to consider. There may be 
>> nothing to do, though, since that happens way after backport.
>>
> 
> 
> +1 from me as well. CHANGES is annoying atm, any automation appreciated.
> 

Thanks for all the feedback. I try to work out something more detailed aka 
patch that we can discuss then.

Regards

Rüdiger

Re: RFC: Documenting changes in the CHANGES file

[Stefan Eissing]

> Am 02.06.2020 um 14:11 schrieb Daniel Ruggeri :
> 
> On 6/1/2020 6:23 AM, Yann Ylavic wrote:
>> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem 
>>  wrote:
>> 
>>> Reviewing our backport process I noticed that in many cases a clean merge 
>>> via svn merge fails due to conflicts in CHANGES. While
>>> these are easy to solve it puts IMHO unnecessary extra work on the backport 
>>> process, both for reviewing and for actually doing the
>>> backport. How about if we change the way we document changes the following 
>>> way:
>>> 
>>> 1. We create a changes-fragments directory (name to be determined) at the 
>>> top level.
>>> 2. For each release we create a subdirectory such that we end up with the 
>>> following structure:
>>> 
>>>changes-fragments/
>>>  2.4.41/
>>>  2.4.42/
>>>  2.4.43/
>>>  2.4.44/
>>> 
>>> 3. Each directory contains the changes for each release and each change 
>>> entry is a single file.
>>> 4. We have a script that builds our current CHANGES file from the content 
>>> in changes-fragments directories with the help of
>>>a template or at least some sort of header / footer that is static.
>>> 5. This script can be called either manually and we commit the resulting 
>>> CHANGES file as we like just like the x-forms commits
>>>for documentation plus this script is called by the release scripts from 
>>> Daniel as part of the preparation of rolling a
>>>release.
>>> 
>> +1 from me, I don't volonteer for the scripts though :)
>> 
>> Regards;
>> Yann.
>> 
> Hi, Yann;
> 
> I'm open to whatever... and don't mind writing or tweaking scripts once we 
> decide on an approach :-)
> 
> While we are discussing ideas in this neighborhood, one thing to keep in mind 
> is that during release of security fixes, sometimes there are items added to 
> CHANGES and sometimes CHANGES is modified to add CVE information. There have 
> been minor bumps in the road where these patches don't always apply cleanly. 
> So, if possible, it would be great to consider. There may be nothing to do, 
> though, since that happens way after backport.
> 


+1 from me as well. CHANGES is annoying atm, any automation appreciated.

Cheers, Stefan

Re: RFC: Documenting changes in the CHANGES file

[Daniel Ruggeri]

On 6/1/2020 6:23 AM, Yann Ylavic wrote:
> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem  wrote:
>> Reviewing our backport process I noticed that in many cases a clean merge 
>> via svn merge fails due to conflicts in CHANGES. While
>> these are easy to solve it puts IMHO unnecessary extra work on the backport 
>> process, both for reviewing and for actually doing the
>> backport. How about if we change the way we document changes the following 
>> way:
>>
>> 1. We create a changes-fragments directory (name to be determined) at the 
>> top level.
>> 2. For each release we create a subdirectory such that we end up with the 
>> following structure:
>>
>>changes-fragments/
>>  2.4.41/
>>  2.4.42/
>>  2.4.43/
>>  2.4.44/
>>
>> 3. Each directory contains the changes for each release and each change 
>> entry is a single file.
>> 4. We have a script that builds our current CHANGES file from the content in 
>> changes-fragments directories with the help of
>>a template or at least some sort of header / footer that is static.
>> 5. This script can be called either manually and we commit the resulting 
>> CHANGES file as we like just like the x-forms commits
>>for documentation plus this script is called by the release scripts from 
>> Daniel as part of the preparation of rolling a
>>release.
> +1 from me, I don't volonteer for the scripts though :)
>
> Regards;
> Yann.

Hi, Yann;

I'm open to whatever... and don't mind writing or tweaking scripts once
we decide on an approach :-)

While we are discussing ideas in this neighborhood, one thing to keep in
mind is that during release of security fixes, sometimes there are items
added to CHANGES and sometimes CHANGES is modified to add CVE
information. There have been minor bumps in the road where these patches
don't always apply cleanly. So, if possible, it would be great to
consider. There may be nothing to do, though, since that happens way
after backport.

-- 
Daniel Ruggeri

Re: RFC: Documenting changes in the CHANGES file

[Eric Covener]

On Fri, May 29, 2020 at 3:30 PM Ruediger Pluem  wrote:
>
> Reviewing our backport process I noticed that in many cases a clean merge via 
> svn merge fails due to conflicts in CHANGES. While
> these are easy to solve it puts IMHO unnecessary extra work on the backport 
> process, both for reviewing and for actually doing the
> backport. How about if we change the way we document changes the following 
> way:
>
> 1. We create a changes-fragments directory (name to be determined) at the top 
> level.
> 2. For each release we create a subdirectory such that we end up with the 
> following structure:
>
>changes-fragments/
>  2.4.41/
>  2.4.42/
>  2.4.43/
>  2.4.44/
>
> 3. Each directory contains the changes for each release and each change entry 
> is a single file.
> 4. We have a script that builds our current CHANGES file from the content in 
> changes-fragments directories with the help of
>a template or at least some sort of header / footer that is static.
> 5. This script can be called either manually and we commit the resulting 
> CHANGES file as we like just like the x-forms commits
>for documentation plus this script is called by the release scripts from 
> Daniel as part of the preparation of rolling a
>release.

If we removed or generalized the banner at the top of each changes,
and added extra whitespace between entries, would svn merge push stuff
to the top any better?
I don't know if it would hunt for more non-whitespace context to try
to figure out how to merge.

Re: RFC: Documenting changes in the CHANGES file

[Graham Leggett]

On 29 May 2020, at 21:30, Ruediger Pluem  wrote:

> Reviewing our backport process I noticed that in many cases a clean merge via 
> svn merge fails due to conflicts in CHANGES. While
> these are easy to solve it puts IMHO unnecessary extra work on the backport 
> process, both for reviewing and for actually doing the
> backport. How about if we change the way we document changes the following 
> way:
> 
> 1. We create a changes-fragments directory (name to be determined) at the top 
> level.
> 2. For each release we create a subdirectory such that we end up with the 
> following structure:
> 
>   changes-fragments/
> 2.4.41/
> 2.4.42/
> 2.4.43/
> 2.4.44/
> 
> 3. Each directory contains the changes for each release and each change entry 
> is a single file.
> 4. We have a script that builds our current CHANGES file from the content in 
> changes-fragments directories with the help of
>   a template or at least some sort of header / footer that is static.
> 5. This script can be called either manually and we commit the resulting 
> CHANGES file as we like just like the x-forms commits
>   for documentation plus this script is called by the release scripts from 
> Daniel as part of the preparation of rolling a
>   release.

I’m keen for a simpler version of this that doesn't create additional steps for 
people.

How about something like this:

1. We create a changes-fragments directory (name to be determined) at the top 
level.
2. The changes-fragments directory contains the changes for each release and 
each change entry is a single file.
3. We update the Makefiles so that if any files are found to exist in 
changes-fragments, those files are moved to the top of CHANGES and then 
deleted. For all builds except for backports, this will be a silent noop. We 
would need some kind of token to force it to be a non-noop in release branches.

What this means is - after every backport, which won’t conflict because changes 
is in a unique file as you describe above, the person performs a build to 
verify that the change is ok. That build automatically sorts out the CHANGES 
file, and the attempt to commit the backport updates changes.

To summarise, with the above, people put changes in changes-fragments 
directory, and that’s it. Everything else is automated as part of the normal 
build, no special scripts, no extra steps, nothing for humans to forget.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: RFC: Documenting changes in the CHANGES file

[Jim Jagielski]

Works for me.

> On May 29, 2020, at 3:30 PM, Ruediger Pluem  wrote:
> 
> Reviewing our backport process I noticed that in many cases a clean merge via 
> svn merge fails due to conflicts in CHANGES. While
> these are easy to solve it puts IMHO unnecessary extra work on the backport 
> process, both for reviewing and for actually doing the
> backport. How about if we change the way we document changes the following 
> way:
> 
> 1. We create a changes-fragments directory (name to be determined) at the top 
> level.
> 2. For each release we create a subdirectory such that we end up with the 
> following structure:
> 
>   changes-fragments/
> 2.4.41/
> 2.4.42/
> 2.4.43/
> 2.4.44/
> 
> 3. Each directory contains the changes for each release and each change entry 
> is a single file.
> 4. We have a script that builds our current CHANGES file from the content in 
> changes-fragments directories with the help of
>   a template or at least some sort of header / footer that is static.
> 5. This script can be called either manually and we commit the resulting 
> CHANGES file as we like just like the x-forms commits
>   for documentation plus this script is called by the release scripts from 
> Daniel as part of the preparation of rolling a
>   release.
> 
> 
> Regards
> 
> Rüdiger

Re: RFC: Documenting changes in the CHANGES file

[Yann Ylavic]

On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem  wrote:
>
> Reviewing our backport process I noticed that in many cases a clean merge via 
> svn merge fails due to conflicts in CHANGES. While
> these are easy to solve it puts IMHO unnecessary extra work on the backport 
> process, both for reviewing and for actually doing the
> backport. How about if we change the way we document changes the following 
> way:
>
> 1. We create a changes-fragments directory (name to be determined) at the top 
> level.
> 2. For each release we create a subdirectory such that we end up with the 
> following structure:
>
>changes-fragments/
>  2.4.41/
>  2.4.42/
>  2.4.43/
>  2.4.44/
>
> 3. Each directory contains the changes for each release and each change entry 
> is a single file.
> 4. We have a script that builds our current CHANGES file from the content in 
> changes-fragments directories with the help of
>a template or at least some sort of header / footer that is static.
> 5. This script can be called either manually and we commit the resulting 
> CHANGES file as we like just like the x-forms commits
>for documentation plus this script is called by the release scripts from 
> Daniel as part of the preparation of rolling a
>release.

+1 from me, I don't volonteer for the scripts though :)

Regards;
Yann.

RFC: Documenting changes in the CHANGES file

[Ruediger Pluem]

Reviewing our backport process I noticed that in many cases a clean merge via 
svn merge fails due to conflicts in CHANGES. While
these are easy to solve it puts IMHO unnecessary extra work on the backport 
process, both for reviewing and for actually doing the
backport. How about if we change the way we document changes the following way:

1. We create a changes-fragments directory (name to be determined) at the top 
level.
2. For each release we create a subdirectory such that we end up with the 
following structure:

   changes-fragments/
 2.4.41/
 2.4.42/
 2.4.43/
 2.4.44/

3. Each directory contains the changes for each release and each change entry 
is a single file.
4. We have a script that builds our current CHANGES file from the content in 
changes-fragments directories with the help of
   a template or at least some sort of header / footer that is static.
5. This script can be called either manually and we commit the resulting 
CHANGES file as we like just like the x-forms commits
   for documentation plus this script is called by the release scripts from 
Daniel as part of the preparation of rolling a
   release.


Regards

Rüdiger

Re: RFC: mod_ssl features to dump for 2.5

[Giovanni Bechis]

On 5/6/20 1:01 PM, Joe Orton wrote:
> On Wed, May 06, 2020 at 11:44:37AM +0100, Joe Orton wrote:
>> On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote:
>>> On 5/4/20 3:49 PM, Joe Orton wrote:
 d) SSLRandomSeed.  This might have made sense in 1998 but at least with 
 OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd 
 should not be doing RAND seeding ever.  Currently mod_ssl will splat 
 random stack data, time() and the pid into the RNG state for each new 
 connection.  Unless someone can prove this is valuable and the OpenSSL 
 PRNG is somehow broken OOTB, I think this code + directive should be 
 dropped for OpenSSL 1.1.1+, including EGD support etc.
>>>
>>> Do we drop it only for OpenSSL 1.1.1 or are there other older versions of 
>>> OpenSSL where this is save to drop?
>>
>> From https://wiki.openssl.org/index.php/Random_fork-safety it seems like 
>> there is some reason to believe the <1.1.1 RNG is not safe after fork 
>> unless you help it.
>>
>> I was looking at the Fedora default mod_ssl config which does have a 
>> default "SSLRandom", but the example httpd-ssl.conf shipped does not. So 
>> *maybe* configuring SSLRandomSeed is useful, but really if it is not 
>> needed by default we should do something by default, which we don't.
> 
> ^ Apologies for garbled grammar, I meant:
> 
> "if it IS needed by default, we should do something by default"
> 
> ... and we *do* have something configured by default:
> 
> # Note: The following must must be present to support
> #   starting without SSL on platforms with no /dev/random equivalent
> #   but a statically compiled-in mod_ssl.
> #
> 
> SSLRandomSeed startup builtin
> SSLRandomSeed connect builtin
> 
> 
> but if OpenSSL does not have entropy source beyond that provided by 
> mod_ssl calling getpid() and time() it is IMO far better to fail to 
> start up.
> 
> So maybe we should still call RAND_status() and fail startup if the PRNG 
> is not initialized correctly?
> 
I think we should fail startup, it's better to fail then to give the user a 
false sense of security and use a poor PRNG.

 Giovanni

Re: RFC: mod_ssl features to dump for 2.5

[Joe Orton]

On Wed, May 06, 2020 at 11:44:37AM +0100, Joe Orton wrote:
> On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote:
> > On 5/4/20 3:49 PM, Joe Orton wrote:
> > > d) SSLRandomSeed.  This might have made sense in 1998 but at least with 
> > > OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd 
> > > should not be doing RAND seeding ever.  Currently mod_ssl will splat 
> > > random stack data, time() and the pid into the RNG state for each new 
> > > connection.  Unless someone can prove this is valuable and the OpenSSL 
> > > PRNG is somehow broken OOTB, I think this code + directive should be 
> > > dropped for OpenSSL 1.1.1+, including EGD support etc.
> > 
> > Do we drop it only for OpenSSL 1.1.1 or are there other older versions of 
> > OpenSSL where this is save to drop?
> 
> From https://wiki.openssl.org/index.php/Random_fork-safety it seems like 
> there is some reason to believe the <1.1.1 RNG is not safe after fork 
> unless you help it.
> 
> I was looking at the Fedora default mod_ssl config which does have a 
> default "SSLRandom", but the example httpd-ssl.conf shipped does not. So 
> *maybe* configuring SSLRandomSeed is useful, but really if it is not 
> needed by default we should do something by default, which we don't.

^ Apologies for garbled grammar, I meant:

"if it IS needed by default, we should do something by default"

... and we *do* have something configured by default:

# Note: The following must must be present to support
#   starting without SSL on platforms with no /dev/random equivalent
#   but a statically compiled-in mod_ssl.
#

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin


but if OpenSSL does not have entropy source beyond that provided by 
mod_ssl calling getpid() and time() it is IMO far better to fail to 
start up.

So maybe we should still call RAND_status() and fail startup if the PRNG 
is not initialized correctly?

Regards, Joe

Re: RFC: mod_ssl features to dump for 2.5

[Joe Orton]

On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote:
> On 5/4/20 3:49 PM, Joe Orton wrote:
> > d) SSLRandomSeed.  This might have made sense in 1998 but at least with 
> > OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd 
> > should not be doing RAND seeding ever.  Currently mod_ssl will splat 
> > random stack data, time() and the pid into the RNG state for each new 
> > connection.  Unless someone can prove this is valuable and the OpenSSL 
> > PRNG is somehow broken OOTB, I think this code + directive should be 
> > dropped for OpenSSL 1.1.1+, including EGD support etc.
> 
> Do we drop it only for OpenSSL 1.1.1 or are there other older versions of 
> OpenSSL where this is save to drop?

>From https://wiki.openssl.org/index.php/Random_fork-safety it seems like 
there is some reason to believe the <1.1.1 RNG is not safe after fork 
unless you help it.

I was looking at the Fedora default mod_ssl config which does have a 
default "SSLRandom", but the example httpd-ssl.conf shipped does not. So 
*maybe* configuring SSLRandomSeed is useful, but really if it is not 
needed by default we should do something by default, which we don't.

(I feel like there should be a assumption in favour of correctness with 
OpenSSL and any code which assumes incorrectness should have very strong 
justification for its continued existence.  Instead we have a tendency 
to carry a lot of code merely because "we've always done it like this".)

> And if we drop how do we drop it? If we can only drop it for OpenSSL 1.1.1 I 
> would be in favour
> of sending a message to the log (INFO level) that it is just ignored. This 
> avoids that a config working with OpenSSL < 1.1.1
> fails with OpenSSL 1.1.1 but the same Apache version.

Very good idea, I'll do it like that.  Thanks for the feedback!

Regards, Joe

Re: RFC: mod_ssl features to dump for 2.5

[Ruediger Pluem]

On 5/4/20 3:49 PM, Joe Orton wrote:
> I'd like to gauge consensus on removing the following mod_ssl features 
> for 2.5.  I am +1 (more or less strongly) on removing all the following:
> 
> a) SSLInsecureRengotiation.  If you haven't patched your clients for 
> CVE-2009-3555 there is no hope.  This should definitely be removed.

+1

> 
> b) SSLRequire - this has been deprecated since it was subsumed into the 
> better "Require expr" interface in 2.4.x. 

+1

> 
> c) Client-initiated renegotiation prevention mechanism.  This was 
> introduced mostly as a temporary workaround for CVE-2009-3555, and as 
> the saying goes, there is nothing as permanent as a temporary 
> workaround.  This already doesn't apply for TLSv1.3, and it doesn't 
> really add much for TLS < v1.3 so I think it can go completely.

+1 to the conclusion you did after Eric's post.

> 
> d) SSLRandomSeed.  This might have made sense in 1998 but at least with 
> OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd 
> should not be doing RAND seeding ever.  Currently mod_ssl will splat 
> random stack data, time() and the pid into the RNG state for each new 
> connection.  Unless someone can prove this is valuable and the OpenSSL 
> PRNG is somehow broken OOTB, I think this code + directive should be 
> dropped for OpenSSL 1.1.1+, including EGD support etc.

Do we drop it only for OpenSSL 1.1.1 or are there other older versions of 
OpenSSL where this is save to drop?
And if we drop how do we drop it? If we can only drop it for OpenSSL 1.1.1 I 
would be in favour
of sending a message to the log (INFO level) that it is just ignored. This 
avoids that a config working with OpenSSL < 1.1.1
fails with OpenSSL 1.1.1 but the same Apache version.

> 
> e) SSLCompression - enabling this has been considered (and documented 
> as) a bad idea for a good while.  IMO we should have "SSLCompression 
> off" the hard-coded default and drop the directive.

+1

Regards

Rüdiger

Re: RFC: mod_ssl features to dump for 2.5

[Joe Orton]

On Mon, May 04, 2020 at 09:59:24AM -0400, Eric Covener wrote:
> On Mon, May 4, 2020 at 9:49 AM Joe Orton  wrote:
> > c) Client-initiated renegotiation prevention mechanism.  This was
> > introduced mostly as a temporary workaround for CVE-2009-3555, and as
> > the saying goes, there is nothing as permanent as a temporary
> > workaround.  This already doesn't apply for TLSv1.3, and it doesn't
> > really add much for TLS < v1.3 so I think it can go completely.
> 
> I am not familiar with this one in mod_ssl but I am familiar with the issue.
> Does it generate distinctive log messages for TLS < 1.3 that are
> useful for e.g. fail2ban?

Yes - APLOGNO(02042) is generated here.

> Has OpenSSL caught up and can we directly kill client-initiated renegotiation?

Great question.  Looks like OpenSSL 1.1.1 added a new option flag, 
SSL_OP_NO_RENEGOTIATION, which does exactly this, so we could use that 
instead of the current code which has to track and intercept handshakes 
manually.  It also sends a TLS alert rather than simply aborting the 
connection, so it's better behaved than the current code.  I'll look at 
switching over to this instead of dropping it instead.  Thanks!

Regards, Joe

Re: RFC: mod_ssl features to dump for 2.5

[Eric Covener]

On Mon, May 4, 2020 at 9:49 AM Joe Orton  wrote:
>
> I'd like to gauge consensus on removing the following mod_ssl features
> for 2.5.  I am +1 (more or less strongly) on removing all the following:
>
> a) SSLInsecureRengotiation.  If you haven't patched your clients for
> CVE-2009-3555 there is no hope.  This should definitely be removed.
>
> b) SSLRequire - this has been deprecated since it was subsumed into the
> better "Require expr" interface in 2.4.x.
>
> c) Client-initiated renegotiation prevention mechanism.  This was
> introduced mostly as a temporary workaround for CVE-2009-3555, and as
> the saying goes, there is nothing as permanent as a temporary
> workaround.  This already doesn't apply for TLSv1.3, and it doesn't
> really add much for TLS < v1.3 so I think it can go completely.

I am not familiar with this one in mod_ssl but I am familiar with the issue.
Does it generate distinctive log messages for TLS < 1.3 that are
useful for e.g. fail2ban?
Has OpenSSL caught up and can we directly kill client-initiated renegotiation?

>
> d) SSLRandomSeed.  This might have made sense in 1998 but at least with
> OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd
> should not be doing RAND seeding ever.  Currently mod_ssl will splat
> random stack data, time() and the pid into the RNG state for each new
> connection.  Unless someone can prove this is valuable and the OpenSSL
> PRNG is somehow broken OOTB, I think this code + directive should be
> dropped for OpenSSL 1.1.1+, including EGD support etc.
>
> e) SSLCompression - enabling this has been considered (and documented
> as) a bad idea for a good while.  IMO we should have "SSLCompression
> off" the hard-coded default and drop the directive.
>

+1 to the others they are long past any practical/transitional use

RFC: mod_ssl features to dump for 2.5

[Joe Orton]

I'd like to gauge consensus on removing the following mod_ssl features 
for 2.5.  I am +1 (more or less strongly) on removing all the following:

a) SSLInsecureRengotiation.  If you haven't patched your clients for 
CVE-2009-3555 there is no hope.  This should definitely be removed.

b) SSLRequire - this has been deprecated since it was subsumed into the 
better "Require expr" interface in 2.4.x. 

c) Client-initiated renegotiation prevention mechanism.  This was 
introduced mostly as a temporary workaround for CVE-2009-3555, and as 
the saying goes, there is nothing as permanent as a temporary 
workaround.  This already doesn't apply for TLSv1.3, and it doesn't 
really add much for TLS < v1.3 so I think it can go completely.

d) SSLRandomSeed.  This might have made sense in 1998 but at least with 
OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd 
should not be doing RAND seeding ever.  Currently mod_ssl will splat 
random stack data, time() and the pid into the RNG state for each new 
connection.  Unless someone can prove this is valuable and the OpenSSL 
PRNG is somehow broken OOTB, I think this code + directive should be 
dropped for OpenSSL 1.1.1+, including EGD support etc.

e) SSLCompression - enabling this has been considered (and documented 
as) a bad idea for a good while.  IMO we should have "SSLCompression 
off" the hard-coded default and drop the directive.

Regards, Joe

[RFC] static type checking for AP_INIT_FLAG etc

[Joe Orton]

Another one I'd like to check consensus on, before disappearing too far 
down the rabbit-hole.

The ap_set_*_slot directive function initializers throw away type safety 
completely since you can pass anything to APR_OFFSETOF(x,y) and it's 
cast to void * regardless.  I've seen one bug because of this in a 
third-party module which was using a bool [sizeof(char)] rather than an 
int with ap_set_int_slot.  r1876823 has another example.

You can get away with "minor" errors like that on little-endian 
platforms since the least significant bytes are in the "right" place 
even if the type is wrong.  So bugs don't show up until customers run 
your code on, just as an example, IBM hardware! ;)

I don't see a way to fix all the code with hard-coded APR_OFFSETOF(), 
but we can offer some alternative wrapper macros which get rid of 
OFFSETOF and check the types at compile-time with some gcc builtin 
magic.  PoC attached.

The failure will look like this one from the mod_proxy_html case:

In file included from mod_proxy_html.c:55:
/home/jorton/src/asf/httpd-git/include/http_config.h:162:5: error: void value 
not ignored as it ought to be
  162 | __builtin_choose_expr(sizeof(actual) == sizeof(expected), result, 
(void)0)
  | ^
/home/jorton/src/asf/httpd-git/include/http_config.h:169:13: note: in expansion 
of macro ‘AP_INIT_CHECKED_TYPE’
  169 | AP_INIT_CHECKED_TYPE(((structname *)0)->fieldname, int, 
\
  | ^~~~
mod_proxy_html.c:1316:5: note: in expansion of macro ‘AP_INIT_TAKE1_INT_SLOT’
 1316 | AP_INIT_TAKE1_INT_SLOT("ProxyHTMLBufSize", proxy_html_conf, bufsz,
  | ^~

which is not totally obvious but at least it's a failure.

Opinions?

Regards, Joe
diff --git a/include/http_config.h b/include/http_config.h
index 2aac6d4325..0c32d94b3c 100644
--- a/include/http_config.h
+++ b/include/http_config.h
@@ -155,6 +155,31 @@ typedef union {
 # define AP_INIT_FLAG(directive, func, mconfig, where, help) \
 { directive, { .flag=func }, mconfig, where, FLAG, help }
 
+#ifdef __GNUC__
+/* Expands to a compile-time error (void)0 if size of actual and
+ * expected arguments do not match, otherwise expands to results. */
+# define AP_INIT_CHECKED_TYPE(actual, expected, result) \
+__builtin_choose_expr(sizeof(actual) == sizeof(expected), result, (void)0)
+#else
+# define AP_INIT_CHECKED_TYPE(actual, expected, result) result
+#endif
+
+# define AP_INIT_TAKE1_INT_SLOT(directive, structname, fieldname, where, help) 
\
+{ directive, { .take1=ap_set_int_slot }, \
+AP_INIT_CHECKED_TYPE(((structname *)0)->fieldname, int, \
+ (void *)APR_OFFSETOF(structname, fieldname)), 
\
+ where, TAKE1, help }
+# define AP_INIT_FLAG_SLOT(directive, structname, fieldname, where, help) \
+{ directive, { .flag=ap_set_flag_slot },\
+AP_INIT_CHECKED_TYPE(((structname *)0)->fieldname, int, \
+ (void *)APR_OFFSETOF(structname, fieldname)), \
+where, FLAG, help }
+# define AP_INIT_FLAG_CHAR_SLOT(directive, structname, fieldname, where, help) 
\
+{ directive, { .flag=ap_set_flag_slot_char },\
+AP_INIT_CHECKED_TYPE(((structname *)0)->fieldname, char, \
+ (void *)APR_OFFSETOF(structname, fieldname)), \
+where, FLAG, help }
+
 #else /* AP_HAVE_DESIGNATED_INITIALIZER */
 
 typedef const char *(*cmd_func) ();
@@ -193,6 +218,15 @@ typedef const char *(*cmd_func) ();
 { directive, func, mconfig, where, TAKE3, help }
 # define AP_INIT_FLAG(directive, func, mconfig, where, help) \
 { directive, func, mconfig, where, FLAG, help }
+# define AP_INIT_TAKE1_INT_SLOT(directive, structname, fieldname, where, help) 
\
+{ directive, ap_set_int_slot }, (void *)APR_OFFSETOF(structname, 
fieldname)), \
+ where, TAKE1, help }
+# define AP_INIT_FLAG_SLOT(directive, structname, fieldname, where, help) \
+{ directive, ap_set_flag_slot, (void *)APR_OFFSETOF(structname, 
fieldname), \
+  where, FLAG, help }
+# define AP_INIT_FLAG_CHAR_SLOT(directive, structname, fieldname, where, help) 
\
+{ directive, ap_set_flag_slot_char, APR_OFFSETOF(structname, fieldname)), \
+where, FLAG, help }
 
 #endif /* AP_HAVE_DESIGNATED_INITIALIZER */
 
diff --git a/modules/aaa/mod_authnz_ldap.c b/modules/aaa/mod_authnz_ldap.c
index 08f5fa1bc9..a0d55aa8db 100644
--- a/modules/aaa/mod_authnz_ldap.c
+++ b/modules/aaa/mod_authnz_ldap.c
@@ -1755,12 +1755,12 @@ static const command_rec authnz_ldap_cmds[] =
 AP_INIT_TAKE1("AuthLDAPBindPassword", set_bind_password, NULL, OR_AUTHCFG,
   "Password to use to bind to LDAP server. If not provided, 
will do an anonymous bind."),
 
-AP_INIT_FLAG("AuthLDAPBindAuthoritative", ap_set_flag_slot,
-  (void *)APR_OFFSETOF(authn_ldap_config_t, 

Re: [RFC] optional Listen options= argument

[Ruediger Pluem]

On 4/21/20 6:02 PM, Joe Orton wrote:
> On Tue, Apr 21, 2020 at 03:13:47PM +0100, Joe Orton wrote:
>> On Tue, Apr 21, 2020 at 03:37:04PM +0200, Ruediger Pluem wrote:
>>> Shouldn't that be argc < 2?
>>
>> It is < 3 to make the second arg truly optional, so a proto default is 
> 
> No, you were right the logic was borked.
> 
> Updated patch which fixes this, and checks the protocol name for the 
> obvious typo problem attached.  Thanks for reviews.
> 

Welcome. Looks good now.

Regards

Rüdiger

Re: [RFC] optional Listen options= argument

[Joe Orton]

On Tue, Apr 21, 2020 at 03:13:47PM +0100, Joe Orton wrote:
> On Tue, Apr 21, 2020 at 03:37:04PM +0200, Ruediger Pluem wrote:
> > Shouldn't that be argc < 2?
> 
> It is < 3 to make the second arg truly optional, so a proto default is 

No, you were right the logic was borked.

Updated patch which fixes this, and checks the protocol name for the 
obvious typo problem attached.  Thanks for reviews.

commit e9161f977d7633baf1ef34890f0de31058353c97
Author: Joe Orton 
Date:   Mon Apr 20 16:22:06 2020 +0100

Add "ListenFree" directive to create listener with APR_SO_FREEBIND set
(for use with an IP address which is not yet available on the system).

Reimplement "use_specific_errors" listener flag under generic
ap_listen_rec flags field to hold both these options.

* include/ap_listen.h: Add AP_LISTEN_* flags.
  (ap_listen_rec): Rename use_specific_errors to flags.

* server/listen.c (make_sock): Set APR_SO_FREEBIND if
  AP_LISTEN_FREEBIND flag is set on listener.
  (alloc_listener): Take flags argument.
  (ap_setup_listeners): Set AP_LISTEN_SPECIFIC_ERRORS flag here.
  (ap_set_listener): Parse optional options=... argument.
  (ap_duplicate_listeners): Duplicate flags.

Submitted by: jkaluza, Lubos Uhliarik , jorton
PR: 61865

diff --git a/include/ap_listen.h b/include/ap_listen.h
index 9cbaaa4910..2329cae70c 100644
--- a/include/ap_listen.h
+++ b/include/ap_listen.h
@@ -38,6 +38,11 @@ typedef struct ap_slave_t ap_slave_t;
 typedef struct ap_listen_rec ap_listen_rec;
 typedef apr_status_t (*accept_function)(void **csd, ap_listen_rec *lr, 
apr_pool_t *ptrans);
 
+/* Flags for ap_listen_rec.flags */
+#define AP_LISTEN_SPECIFIC_ERRORS (0x0001)
+#define AP_LISTEN_FREEBIND(0x0002)
+#define AP_LISTEN_REUSEPORT   (0x0004)
+
 /**
  * @brief Apache's listeners record.
  *
@@ -73,10 +78,9 @@ struct ap_listen_rec {
 ap_slave_t *slave;
 
 /**
- * Allow the accept_func to return a wider set of return codes
+ * Various AP_LISTEN_* flags.
  */
-int use_specific_errors;
-
+apr_uint32_t flags;
 };
 
 /**
diff --git a/include/ap_mmn.h b/include/ap_mmn.h
index 24ac648ac9..1271ce18ed 100644
--- a/include/ap_mmn.h
+++ b/include/ap_mmn.h
@@ -628,14 +628,15 @@
  * 20200331.2 (2.5.1-dev)  Add ap_proxy_should_override to mod_proxy.h
  * 20200331.3 (2.5.1-dev)  Add ap_parse_request_line() and
  * ap_check_request_header()
+ * 20200420.0 (2.5.1-dev)  Add flags to listen_rec in place of 
use_specific_errors
  */
 
 #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
 
 #ifndef MODULE_MAGIC_NUMBER_MAJOR
-#define MODULE_MAGIC_NUMBER_MAJOR 20200331
+#define MODULE_MAGIC_NUMBER_MAJOR 20200420
 #endif
-#define MODULE_MAGIC_NUMBER_MINOR 3/* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 0/* 0...n */
 
 /**
  * Determine if the server's current MODULE_MAGIC_NUMBER is at least a
diff --git a/os/unix/unixd.c b/os/unix/unixd.c
index bde859022b..3b0e695727 100644
--- a/os/unix/unixd.c
+++ b/os/unix/unixd.c
@@ -323,7 +323,7 @@ AP_DECLARE(apr_status_t) ap_unixd_accept(void **accepted, 
ap_listen_rec *lr,
 }
   
 /* Let the caller handle slightly more varied return values */
-if (lr->use_specific_errors && ap_accept_error_is_nonfatal(status)) { 
+if ((lr->flags & AP_LISTEN_SPECIFIC_ERRORS) && 
ap_accept_error_is_nonfatal(status)) {
 return status;
 }
 
diff --git a/server/listen.c b/server/listen.c
index 87a4bafe80..f9c8ff5a54 100644
--- a/server/listen.c
+++ b/server/listen.c
@@ -150,7 +150,8 @@ static apr_status_t make_sock(apr_pool_t *p, ap_listen_rec 
*server, int do_bind_
 #endif
 
 #if defined(SO_REUSEPORT)
-if (ap_have_so_reuseport && ap_listencbratio > 0) {
+if (server->flags & AP_LISTEN_REUSEPORT
+|| (ap_have_so_reuseport && ap_listencbratio > 0)) {
 int thesock;
 apr_os_sock_get(, s);
 if (setsockopt(thesock, SOL_SOCKET, SO_REUSEPORT,
@@ -166,6 +167,21 @@ static apr_status_t make_sock(apr_pool_t *p, ap_listen_rec 
*server, int do_bind_
 }
 #endif
 
+
+#if defined(APR_SO_FREEBIND)
+if (server->flags & AP_LISTEN_FREEBIND) {
+if (apr_socket_opt_set(s, APR_SO_FREEBIND, one) < 0) {
+stat = apr_get_netos_error();
+ap_log_perror(APLOG_MARK, APLOG_CRIT, stat, p, APLOGNO()
+  "make_sock: apr_socket_opt_set: "
+  "error setting APR_SO_FREEBIND");
+apr_socket_close(s);
+return stat;
+}
+}
+#endif
+
+
 if (do_bind_listen) {
 #if APR_HAVE_IPV6
 if (server->bind_addr->family == APR_INET6) {
@@ -467,7 +483,7 @@ static int find_listeners(ap_listen_rec **from, 
ap_listen_rec **to,
 static const char *alloc_listener(process_rec *process, const char *addr,
   apr_port_t port, const char* proto,
   const char *scope_id, void *slave,
- 

Re: [RFC] optional Listen options= argument

[Yann Ylavic]

On Tue, Apr 21, 2020 at 4:13 PM Joe Orton  wrote:
>
> If it is safe to assume "=" can never appear in a
> protocol name, we could catch any proto with "=" and make that a config
> error again.

Looks sensible to me, the proto is supposed to be a scheme (so ALNUM
or [.+-], IIRC).

Re: [RFC] optional Listen options= argument

[Yann Ylavic]

On Tue, Apr 21, 2020 at 2:53 PM Joe Orton  wrote:
>
> Opinions?  Is there still consensus that extending Listen like this is a
> good idea?

+1, nice.

I also like that we can set reuseport without ListenCoresBucketsRatio
> 0, both are orthogonal I think.

Re: [RFC] optional Listen options= argument

[Joe Orton]

On Tue, Apr 21, 2020 at 03:37:04PM +0200, Ruediger Pluem wrote:
> Looks good in general apart from the comment below.
> 
> On 4/21/20 2:53 PM, Joe Orton wrote:
> > @@ -1058,7 +1104,24 @@ AP_DECLARE_NONSTD(const char *) 
> > ap_set_listener(cmd_parms *cmd, void *dummy,
> >  return "Port must be specified";
> >  }
> >  
> > -if (argc != 2) {
> > +if (argc == 3) {
> > +if (strncasecmp(argv[2], "options=", 8)) {
> > +return "Third argument to Listen must be options=...";
> > +}
> > +
> > +err = parse_listen_flags(cmd->temp_pool, argv[2] + 8, );
> > +if (err) {
> > +return err;
> > +}
> > +}
> > +
> > +if (argc == 2 && strncasecmp(argv[1], "options=", 8) == 0) {
> > +err = parse_listen_flags(cmd->temp_pool, argv[1] + 8, );
> > +if (err) {
> > +return err;
> > +}
> > +}
> > +else if (argc < 3) {
> 
> Shouldn't that be argc < 2?

It is < 3 to make the second arg truly optional, so a proto default is 
picked either for the 1-arg form or for the 2-arg form where the second 
arg is options= (i.e. first if condition applies) i.e. 

  Listen 80 options=foo

Making the protocol option truly optional was one of the review feedback 
comments in the original thread.

No strong opinion here on whether that's right, but it reminds me that 
it leads to a fragile outcome, e.g.

  Listen 80 optons=foo

silently succeeds with "optons=foo" as the protocol name (not sure what 
it does with it).  If it is safe to assume "=" can never appear in a 
protocol name, we could catch any proto with "=" and make that a config 
error again.

Alternatively, can simply make the protocol a required option if 
options= is used.

Regards, Joe

Re: [RFC] optional Listen options= argument

[Ruediger Pluem]

Looks good in general apart from the comment below.

On 4/21/20 2:53 PM, Joe Orton wrote:
> @@ -1058,7 +1104,24 @@ AP_DECLARE_NONSTD(const char *) 
> ap_set_listener(cmd_parms *cmd, void *dummy,
>  return "Port must be specified";
>  }
>  
> -if (argc != 2) {
> +if (argc == 3) {
> +if (strncasecmp(argv[2], "options=", 8)) {
> +return "Third argument to Listen must be options=...";
> +}
> +
> +err = parse_listen_flags(cmd->temp_pool, argv[2] + 8, );
> +if (err) {
> +return err;
> +}
> +}
> +
> +if (argc == 2 && strncasecmp(argv[1], "options=", 8) == 0) {
> +err = parse_listen_flags(cmd->temp_pool, argv[1] + 8, );
> +if (err) {
> +return err;
> +}
> +}
> +else if (argc < 3) {

Shouldn't that be argc < 2?

>  if (port == 443) {
>  proto = "https";
>  } else {

Regards

Rüdiger

Re: [RFC] optional Listen options= argument

[Luca Toscano]

On Tue, Apr 21, 2020 at 3:12 PM Eric Covener  wrote:
>
> On Tue, Apr 21, 2020 at 8:53 AM Joe Orton  wrote:
> >
> > A previous conversation [1] about optionally enabling socket options for
> > Listen seemed to gain consensus around adding an optional argument,
> > rather than multiple alternative Listen-like directives.
> >
> > I've attached a patch based on work by both Jan Kaluza and Lubos
> > Uhliarik which implements this, updated for trunk.  Syntax used is:
> >
> >   Listen [IP-address:]portnumber [protocol] [options=keyword,keyword,...]
> >
> > where options is a comma-separated list of keywords.  In this patch the
> > "reuseport" and "freebind" keywords are supported for APR_SO_REUSEPORT
> > and APR_SO_FREEBIND respectively.  Key/value keywords could be used to
> > allow per-listener backlog, TCP buffer sizes etc, though non-boolean
> > options will require extending ap_listen_rec so that needs care.
> >
> > Opinions?  Is there still consensus that extending Listen like this is a
> > good idea?
> >
> > Regards, Joe
> >
> > [1] 
> > http://mail-archives.apache.org/mod_mbox/httpd-dev/201603.mbox/%3c56dd68e5.2040...@redhat.com%3e
>
>
> LGTM

+1 very nice

Re: [RFC] optional Listen options= argument

[Eric Covener]

On Tue, Apr 21, 2020 at 8:53 AM Joe Orton  wrote:
>
> A previous conversation [1] about optionally enabling socket options for
> Listen seemed to gain consensus around adding an optional argument,
> rather than multiple alternative Listen-like directives.
>
> I've attached a patch based on work by both Jan Kaluza and Lubos
> Uhliarik which implements this, updated for trunk.  Syntax used is:
>
>   Listen [IP-address:]portnumber [protocol] [options=keyword,keyword,...]
>
> where options is a comma-separated list of keywords.  In this patch the
> "reuseport" and "freebind" keywords are supported for APR_SO_REUSEPORT
> and APR_SO_FREEBIND respectively.  Key/value keywords could be used to
> allow per-listener backlog, TCP buffer sizes etc, though non-boolean
> options will require extending ap_listen_rec so that needs care.
>
> Opinions?  Is there still consensus that extending Listen like this is a
> good idea?
>
> Regards, Joe
>
> [1] 
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201603.mbox/%3c56dd68e5.2040...@redhat.com%3e


LGTM

-- 
Eric Covener
cove...@gmail.com

[RFC] optional Listen options= argument

[Joe Orton]

A previous conversation [1] about optionally enabling socket options for 
Listen seemed to gain consensus around adding an optional argument, 
rather than multiple alternative Listen-like directives.

I've attached a patch based on work by both Jan Kaluza and Lubos 
Uhliarik which implements this, updated for trunk.  Syntax used is:

  Listen [IP-address:]portnumber [protocol] [options=keyword,keyword,...]

where options is a comma-separated list of keywords.  In this patch the 
"reuseport" and "freebind" keywords are supported for APR_SO_REUSEPORT 
and APR_SO_FREEBIND respectively.  Key/value keywords could be used to 
allow per-listener backlog, TCP buffer sizes etc, though non-boolean 
options will require extending ap_listen_rec so that needs care.

Opinions?  Is there still consensus that extending Listen like this is a 
good idea?

Regards, Joe

[1] 
http://mail-archives.apache.org/mod_mbox/httpd-dev/201603.mbox/%3c56dd68e5.2040...@redhat.com%3e
diff --git a/include/ap_listen.h b/include/ap_listen.h
index 9cbaaa4910..2329cae70c 100644
--- a/include/ap_listen.h
+++ b/include/ap_listen.h
@@ -38,6 +38,11 @@ typedef struct ap_slave_t ap_slave_t;
 typedef struct ap_listen_rec ap_listen_rec;
 typedef apr_status_t (*accept_function)(void **csd, ap_listen_rec *lr, 
apr_pool_t *ptrans);
 
+/* Flags for ap_listen_rec.flags */
+#define AP_LISTEN_SPECIFIC_ERRORS (0x0001)
+#define AP_LISTEN_FREEBIND(0x0002)
+#define AP_LISTEN_REUSEPORT   (0x0004)
+
 /**
  * @brief Apache's listeners record.
  *
@@ -73,10 +78,9 @@ struct ap_listen_rec {
 ap_slave_t *slave;
 
 /**
- * Allow the accept_func to return a wider set of return codes
+ * Various AP_LISTEN_* flags.
  */
-int use_specific_errors;
-
+apr_uint32_t flags;
 };
 
 /**
diff --git a/include/ap_mmn.h b/include/ap_mmn.h
index 24ac648ac9..1271ce18ed 100644
--- a/include/ap_mmn.h
+++ b/include/ap_mmn.h
@@ -628,14 +628,15 @@
  * 20200331.2 (2.5.1-dev)  Add ap_proxy_should_override to mod_proxy.h
  * 20200331.3 (2.5.1-dev)  Add ap_parse_request_line() and
  * ap_check_request_header()
+ * 20200420.0 (2.5.1-dev)  Add flags to listen_rec in place of 
use_specific_errors
  */
 
 #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
 
 #ifndef MODULE_MAGIC_NUMBER_MAJOR
-#define MODULE_MAGIC_NUMBER_MAJOR 20200331
+#define MODULE_MAGIC_NUMBER_MAJOR 20200420
 #endif
-#define MODULE_MAGIC_NUMBER_MINOR 3/* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 0/* 0...n */
 
 /**
  * Determine if the server's current MODULE_MAGIC_NUMBER is at least a
diff --git a/os/unix/unixd.c b/os/unix/unixd.c
index bde859022b..3b0e695727 100644
--- a/os/unix/unixd.c
+++ b/os/unix/unixd.c
@@ -323,7 +323,7 @@ AP_DECLARE(apr_status_t) ap_unixd_accept(void **accepted, 
ap_listen_rec *lr,
 }
   
 /* Let the caller handle slightly more varied return values */
-if (lr->use_specific_errors && ap_accept_error_is_nonfatal(status)) { 
+if ((lr->flags & AP_LISTEN_SPECIFIC_ERRORS) && 
ap_accept_error_is_nonfatal(status)) {
 return status;
 }
 
diff --git a/server/listen.c b/server/listen.c
index 87a4bafe80..3657ba65c7 100644
--- a/server/listen.c
+++ b/server/listen.c
@@ -150,7 +150,8 @@ static apr_status_t make_sock(apr_pool_t *p, ap_listen_rec 
*server, int do_bind_
 #endif
 
 #if defined(SO_REUSEPORT)
-if (ap_have_so_reuseport && ap_listencbratio > 0) {
+if (server->flags & AP_LISTEN_REUSEPORT
+|| (ap_have_so_reuseport && ap_listencbratio > 0)) {
 int thesock;
 apr_os_sock_get(, s);
 if (setsockopt(thesock, SOL_SOCKET, SO_REUSEPORT,
@@ -166,6 +167,21 @@ static apr_status_t make_sock(apr_pool_t *p, ap_listen_rec 
*server, int do_bind_
 }
 #endif
 
+
+#if defined(APR_SO_FREEBIND)
+if (server->flags & AP_LISTEN_FREEBIND) {
+if (apr_socket_opt_set(s, APR_SO_FREEBIND, one) < 0) {
+stat = apr_get_netos_error();
+ap_log_perror(APLOG_MARK, APLOG_CRIT, stat, p, APLOGNO()
+  "make_sock: apr_socket_opt_set: "
+  "error setting APR_SO_FREEBIND");
+apr_socket_close(s);
+return stat;
+   }
+   }
+#endif
+
+
 if (do_bind_listen) {
 #if APR_HAVE_IPV6
 if (server->bind_addr->family == APR_INET6) {
@@ -467,7 +483,7 @@ static int find_listeners(ap_listen_rec **from, 
ap_listen_rec **to,
 static const char *alloc_listener(process_rec *process, const char *addr,
   apr_port_t port, const char* proto,
   const char *scope_id, void *slave,
-  apr_pool_t *temp_pool)
+  apr_pool_t *temp_pool, apr_uint32_t flags)
 {
 ap_listen_rec *last;
 apr_status_t status;
@@ -511,6 +527,7 @@ static const char *alloc_listener(process_rec *process, 
const char *addr,
 new->next = 0;
 new->bind_addr = sa;
 

Re: [RFC] fixing mod_cgid error logging

[Joe Orton]

If anybody is interested to test this out I have a 2.4.x backport here:

http://people.apache.org/~jorton/httpd-2.4.x-cgid-fdpassing.patch

which ignores the configure test and hard-codes to enabling the new code 
(unlike code in trunk).

I think we're now at parity between mod_cgi and mod_cgid in stderr 
handling, particularly in terms of failure cases - it's quite 
complicated to follow and test them all, but e.g. execve() failures do 
get logged properly.

There are some interesting diffs between common code across the modules 
which I'm still looking at.  It seems sensible to try to consolidate 
some of this, there are clearly places where mod_cgi alone has received 
fixes for bugs which appear to also apply to mod_cgid... WIP.

Regards, Joe

Re: [RFC] fixing mod_cgid error logging

[Joe Orton]

On Fri, Jul 05, 2019 at 01:39:21PM +0200, Ruediger Pluem wrote:
> How much portable is this and do we have / should have something in 
> APR that does that portability? We probably should guard this with a 
> check for
> 
> #ifndef CMSG_DATA
> #error This module only works on unix platforms with the correct OS support
> #endif

Ah, good call, I'd completely forgotten that mod_proxy_fdpass uses 
exactly the same technique.  I'm guessing it's not really APR material 
since it's a quite Unix-specific.

My two-decade-old copy of Stevens's UNP talks about differences between 
4.4BSD and SVR4, but the API appears to be a POSIX standard these days.

Regards, Joe

Re: [RFC] fixing mod_cgid error logging

[Ruediger Pluem]

On 07/05/2019 12:57 PM, Joe Orton wrote:
> PR 54211 and 60692 track a design problem in mod_cgid: the stderr of 
> spawned CGI scripts is a copy of the main server's stderr.  This is a 
> significant regression from mod_cgi (you lose logging prefixes, 
> per-vhost config, non-file/pipe-logging provider support e.g. syslog)
> 
> I can think of two main approaches to fix this:
> 
> 1) enhance the client/server protocol which cgid uses to be a bit more 
> like FastCGI with headers, record types, etc and multiplex both stderr 
> and stdout over the Unix socket.  We'd need a new thread or process for 
> each new spawned script child to translate CGI stdout/stderr into this 
> protocol, or to completely redesign the cgid_server main loop to be 
> event-driven.  Plus a new bucket type similar to the CGI bucket which 
> handles the protocol client side.
> 
> 2) Create a new pipe for stderr in the client and pass this to the 
> server using Unix fd passing magic for the CGI script to use as stderr.  
> Factor out the CGI bucket from mod_cgi and use this as-is in mod_cgid.
> 
> I think (1) might be a cleaner design in the long run but (2) is going 
> to be vastly simpler to implement.  (2) might take some effort from 
> platform maintainers to work across all Unixes.

How much portable is this and do we have / should have something in APR that 
does that portability?
We probably should guard this with a check for

#ifndef CMSG_DATA
#error This module only works on unix platforms with the correct OS support
#endif

like we do for mod_proxy_fdpass:

APACHE_MODULE(proxy_fdpass, Apache proxy to Unix Daemon Socket module.  
Requires --enable-proxy., $proxy_fdpass_objs, ,
most, [
  AC_CHECK_DECL(CMSG_DATA,,, [
#include 
#include 
  ])
  if test $ac_cv_have_decl_CMSG_DATA = "no"; then
AC_MSG_WARN([Your system does not support CMSG_DATA.])
enable_proxy_fdpass=no
  fi
],proxy)


Regards

Rüdiger

Re: [RFC] fixing mod_cgid error logging

[Stefan Eissing]

No objections from me, as I lack the expertise here. Patch looks readable, 
though. ;)

> Am 05.07.2019 um 12:57 schrieb Joe Orton :
> 
> PR 54211 and 60692 track a design problem in mod_cgid: the stderr of 
> spawned CGI scripts is a copy of the main server's stderr.  This is a 
> significant regression from mod_cgi (you lose logging prefixes, 
> per-vhost config, non-file/pipe-logging provider support e.g. syslog)
> 
> I can think of two main approaches to fix this:
> 
> 1) enhance the client/server protocol which cgid uses to be a bit more 
> like FastCGI with headers, record types, etc and multiplex both stderr 
> and stdout over the Unix socket.  We'd need a new thread or process for 
> each new spawned script child to translate CGI stdout/stderr into this 
> protocol, or to completely redesign the cgid_server main loop to be 
> event-driven.  Plus a new bucket type similar to the CGI bucket which 
> handles the protocol client side.
> 
> 2) Create a new pipe for stderr in the client and pass this to the 
> server using Unix fd passing magic for the CGI script to use as stderr.  
> Factor out the CGI bucket from mod_cgi and use this as-is in mod_cgid.
> 
> I think (1) might be a cleaner design in the long run but (2) is going 
> to be vastly simpler to implement.  (2) might take some effort from 
> platform maintainers to work across all Unixes.
> 
> I'm going to run with (2) in two steps unless there are major 
> objections.
> 
> a) make fd passing work (opt-in via configure switch) if ErrorLog is an 
> fd, by passing that fd directly to the server (fixing PR 60692 only) - 
> PoC attached to show this is relatively simple, +100 lines
> 
> b) then make that work via a new pipe with the CGI bucket abstracted out 
> and used across both mod_cgi/cgid (properly fixing PR 54211)
> 
> Regards, Joe
> 
> 

[RFC] fixing mod_cgid error logging

[Joe Orton]

PR 54211 and 60692 track a design problem in mod_cgid: the stderr of 
spawned CGI scripts is a copy of the main server's stderr.  This is a 
significant regression from mod_cgi (you lose logging prefixes, 
per-vhost config, non-file/pipe-logging provider support e.g. syslog)

I can think of two main approaches to fix this:

1) enhance the client/server protocol which cgid uses to be a bit more 
like FastCGI with headers, record types, etc and multiplex both stderr 
and stdout over the Unix socket.  We'd need a new thread or process for 
each new spawned script child to translate CGI stdout/stderr into this 
protocol, or to completely redesign the cgid_server main loop to be 
event-driven.  Plus a new bucket type similar to the CGI bucket which 
handles the protocol client side.

2) Create a new pipe for stderr in the client and pass this to the 
server using Unix fd passing magic for the CGI script to use as stderr.  
Factor out the CGI bucket from mod_cgi and use this as-is in mod_cgid.

I think (1) might be a cleaner design in the long run but (2) is going 
to be vastly simpler to implement.  (2) might take some effort from 
platform maintainers to work across all Unixes.

I'm going to run with (2) in two steps unless there are major 
objections.

a) make fd passing work (opt-in via configure switch) if ErrorLog is an 
fd, by passing that fd directly to the server (fixing PR 60692 only) - 
PoC attached to show this is relatively simple, +100 lines

b) then make that work via a new pipe with the CGI bucket abstracted out 
and used across both mod_cgi/cgid (properly fixing PR 54211)

Regards, Joe

Index: modules/generators/config5.m4
===
--- modules/generators/config5.m4   (revision 1862592)
+++ modules/generators/config5.m4   (working copy)
@@ -78,4 +78,10 @@
 
 APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/$modpath_current])
 
+AC_ARG_ENABLE(cgid-fdpassing, 
[APACHE_HELP_STRING(--enable-cgid-fdpassing,Enable experimental mod_cgid 
support for fd passing)],
+[if test "$enableval" = "yes"; then
+   AC_DEFINE([HAVE_CGID_FDPASSING], 1, [Enable FD passing support in 
mod_cgid])
+fi
+])
+
 APACHE_MODPATH_FINISH
Index: modules/generators/mod_cgid.c
===
--- modules/generators/mod_cgid.c   (revision 1862592)
+++ modules/generators/mod_cgid.c   (working copy)
@@ -342,15 +342,19 @@
 return close(fd);
 }
 
-/* deal with incomplete reads and signals
- * assume you really have to read buf_size bytes
- */
-static apr_status_t sock_read(int fd, void *vbuf, size_t buf_size)
+/* Read from the socket dealing with incomplete messages and signals.
+ * Returns 0 on success or errno on failure.  Stderr fd passed as
+ * auxiliary data from other end is written to *errfd, or else stderr
+ * fileno if not present. */
+static apr_status_t sock_readhdr(int fd, int *errfd, void *vbuf, size_t 
buf_size)
 {
+int rc;
+#ifndef HAVE_CGID_FDPASSING
 char *buf = vbuf;
-int rc;
 size_t bytes_read = 0;
 
+if (errfd) *errfd = 0;
+
 do {
 do {
 rc = read(fd, buf + bytes_read, buf_size - bytes_read);
@@ -365,9 +369,52 @@
 }
 } while (bytes_read < buf_size);
 
+   
+#else /* with FD passing */
+struct msghdr msg = {0};
+struct iovec vec = {vbuf, buf_size};
+struct cmsghdr *cmsg;
+union {  /* union to ensure alignment */
+struct cmsghdr cm;
+char buf[CMSG_SPACE(sizeof(int))];
+} u;
+
+msg.msg_iov = 
+msg.msg_iovlen = 1;
+
+msg.msg_control = u.buf;
+msg.msg_controllen = sizeof(u.buf);
+
+if (errfd) *errfd = 0;
+
+/* use MSG_WAITALL to skip loop on truncated reads */
+do {
+rc = recvmsg(fd, , MSG_WAITALL);
+} while (rc < 0 && errno == EINTR);
+
+if (rc == 0) {
+return ECONNRESET;
+}
+
+cmsg = CMSG_FIRSTHDR();
+if (errfd
+&& cmsg
+&& cmsg->cmsg_len == CMSG_LEN(sizeof(*errfd))
+&& cmsg->cmsg_level == SOL_SOCKET
+&& cmsg->cmsg_type == SCM_RIGHTS) {
+*errfd = *((int *) CMSG_DATA(cmsg));
+}
+#endif
+
 return APR_SUCCESS;
 }
 
+/* As sock_readhdr but without auxiliary fd passing. */
+static apr_status_t sock_read(int fd, void *vbuf, size_t buf_size)
+{
+return sock_readhdr(fd, NULL, vbuf, buf_size);
+}
+
 /* deal with signals
  */
 static apr_status_t sock_write(int fd, const void *buf, size_t buf_size)
@@ -384,7 +431,7 @@
 return APR_SUCCESS;
 }
 
-static apr_status_t sock_writev(int fd, request_rec *r, int count, ...)
+static apr_status_t sock_writev(int fd, int auxfd, request_rec *r, int count, 
...)
 {
 va_list ap;
 int rc;
@@ -399,9 +446,39 @@
 }
 va_end(ap);
 
+#ifndef HAVE_CGID_FDPASSING
 do {
 rc = writev(fd, vec, count);
 } while (rc < 0 && errno == EINTR);
+#else
+{
+struct msghdr msg = { 0 };
+struct cmsghdr 

RFC: "persistent state" directory default/config/API

[Joe Orton]

I'd like to add a "persistent state" directory with a hard-coded 
default, config directive and API equivalent to the runtimdir in 
config.layout, DefaultRuntimeDir directive and 
ap_runtime_dir_relative().  The "runtime" directory is used for 
transient state which disappears and can be deleted once the server is 
stopped.  This can be safely stored in tmpfs or even created & deleted 
on the fly.  A "persistent state" directory would be for data which is 
expected to persist across restarts.

Example users are the mod_dav_fs lock database, mod_md's MD data store. 
With an API & default, these can have hard-coded default paths so the 
modules work without needing configuration.  The proxy cache root could 
count here too.

Any thoughts/objections?

I'm not sure about naming, maybe simply:

DefaultStateDir -- ap_state_dir_relative() 

and use "statedir" in config.layout since localstatedir is already used 
and is typically set to /var or $prefix.

For Linux/FHS type layouts, statedir could be set to e.g. /var/lib/httpd 
and for layouts like "Apache", maybe $prefix/state or something like 
that would be fine.

Regards, Joe

Re: [RFC/PATCH] mpm_winnt: Fix several issues in the child process shutdown logic

[Evgeny Kotkov]

Evgeny Kotkov  writes:

>  (1) As a part of the process of shutting down worker threads, the code
>  around child.c:1170 currently posts an amount of I/O completion packets
>  equal to the amount of the threads blocked on the I/O completion port.
>  Then it sleeps until all these threads "acknowledge" the completion
>  packets by decrementing the global amount of blocked threads.
>
>  This can be improved to avoid unnecessary Sleep()'s, and make the
>  shutdown faster.  There is no need to block until the threads actually
>  receive the completion, as the shutdown process includes a separate step
>  that waits until the threads exit.  Instead of synchronizing on the
>  amount of the threads blocked on the I/O completion port, we can send
>  the number of IOCP_SHUTDOWN completion packets equal to the total
>  amount of threads and immediately proceed to the next step.

Committed in https://svn.apache.org/r1801635

>   (2) If the shutdown routine hits a timeout while waiting for the worker
>   threads to exit, it uses TerminateThread() to terminate the remaining
>   threads.
>
>   Using TerminateThread() can have dangerous consequences such as
>   deadlocks — say, if the the thread is terminated while holding a lock
>   or a heap lock in the middle of HeapAlloc(), as these locks would not
>   be released.  Or it can corrupt the application state and cause a crash.
>   See https://msdn.microsoft.com/en-us/library/windows/desktop/ms686717
>
>   Presumably, a much better alternative here would be to leave the cleanup
>   to the operating system by calling TerminateProcess().

Committed in https://svn.apache.org/r1801636

>   (3) Assuming (2) is in place, the code around child.c:1170 that waits for
>   multiple thread handles in batches can be simplified.  With (2), there
>   is no difference between ending the wait with one or multiple remaining
>   threads.  (Since we terminate the process if at least one thread is
>   still active when we hit a timeout.)
>
>   Therefore, instead of making an effort to evenly distribute and batch
>   the handles with WaitForMultipleObjects(), we could just start from
>   one end, and wait for one thread handle at a time.

Committed in https://svn.apache.org/r1801637


Regards,
Evgeny Kotkov

[RFC/PATCH] mpm_winnt: Fix several issues in the child process shutdown logic

[Evgeny Kotkov]

Hi all,

Recently we (Ivan Zhakov and I) found several issues in the code responsible
for shutting down a mpm_winnt's child process.

The attached patch should fix these issues:

 (Please note that the changes are combined into a single patch to make the
  review easier, but I'll commit them independently.)

 (1) As a part of the process of shutting down worker threads, the code
 around child.c:1170 currently posts an amount of I/O completion packets
 equal to the amount of the threads blocked on the I/O completion port.
 Then it sleeps until all these threads "acknowledge" the completion
 packets by decrementing the global amount of blocked threads.

 This can be improved to avoid unnecessary Sleep()'s, and make the
 shutdown faster.  There is no need to block until the threads actually
 receive the completion, as the shutdown process includes a separate step
 that waits until the threads exit.  Instead of synchronizing on the
 amount of the threads blocked on the I/O completion port, we can send
 the number of IOCP_SHUTDOWN completion packets equal to the total
 amount of threads and immediately proceed to the next step.

  (2) If the shutdown routine hits a timeout while waiting for the worker
  threads to exit, it uses TerminateThread() to terminate the remaining
  threads.

  Using TerminateThread() can have dangerous consequences such as
  deadlocks — say, if the the thread is terminated while holding a lock
  or a heap lock in the middle of HeapAlloc(), as these locks would not
  be released.  Or it can corrupt the application state and cause a crash.
  See https://msdn.microsoft.com/en-us/library/windows/desktop/ms686717

  Presumably, a much better alternative here would be to leave the cleanup
  to the operating system by calling TerminateProcess().

  (3) Assuming (2) is in place, the code around child.c:1170 that waits for
  multiple thread handles in batches can be simplified.  With (2), there
  is no difference between ending the wait with one or multiple remaining
  threads.  (Since we terminate the process if at least one thread is
  still active when we hit a timeout.)

  Therefore, instead of making an effort to evenly distribute and batch
  the handles with WaitForMultipleObjects(), we could just start from
  one end, and wait for one thread handle at a time.

Note that apart from this, the code around child.c:1146 that shuts down the
listeners, waits, and then proceeds to shutting down the worker threads is
prone to a subtle race.  Since the wait interval is hardcoded to 1 second,
there could still be an accepted connection after it.  And, as the worker
threads are being shut down, it is feasible that this accepted connection
won't ever find a suitable worker thread.  (Eventually, it is going to be
ungracefully closed).  I think that this can be fixed by properly waiting for
the listener threads to exit, and in the meanwhile, this would avoid having
the Sleep(1000) call altogether.  But this is something that I have now left
for future work.

I would greatly appreciate if someone could review or comment on the proposed
changes.  If anyone has an additional insight on the design or planned, but
unaccomplished changes to the mpm_winnt module, I would appreciate hearing
them as well.

Thanks!


Regards,
Evgeny Kotkov
Index: server/mpm/winnt/child.c
===
--- server/mpm/winnt/child.c(revision 1801135)
+++ server/mpm/winnt/child.c(working copy)
@@ -827,18 +827,6 @@ static DWORD __stdcall worker_main(void *thread_nu
 }
 
 
-static void cleanup_thread(HANDLE *handles, int *thread_cnt,
-   int thread_to_clean)
-{
-int i;
-
-CloseHandle(handles[thread_to_clean]);
-for (i = thread_to_clean; i < ((*thread_cnt) - 1); i++)
-handles[i] = handles[i + 1];
-(*thread_cnt)--;
-}
-
-
 /*
  * child_main()
  * Entry point for the main control thread for the child process.
@@ -890,7 +878,6 @@ void child_main(apr_pool_t *pconf, DWORD parent_pi
 HANDLE *child_handles;
 int listener_started = 0;
 int threads_created = 0;
-int watch_thread;
 int time_remains;
 int cld;
 DWORD tid;
@@ -1162,16 +1149,16 @@ void child_main(apr_pool_t *pconf, DWORD parent_pi
 /* Shutdown the worker threads
  * Post worker threads blocked on the ThreadDispatch IOCompletion port
  */
-while (g_blocked_threads > 0) {
+if (g_blocked_threads > 0) {
 ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS, ap_server_conf, 
APLOGNO(00361)
  "Child: %d threads blocked on the completion port",
  g_blocked_threads);
-for (i=g_blocked_threads; i > 0; i--) {
-PostQueuedCompletionStatus(ThreadDispatchIOCP, 0,
-   IOCP_SHUTDOWN, NULL);
-}
-Sleep(1000);
 }
+
+

Re: [RFC] ?

[Jacob Champion]

On 03/08/2017 02:29 AM, Joe Orton wrote:

Final call for yay/nay?


Works great on my machine, +1!

--Jacob

Re: [RFC] ?

[William A Rowe Jr]

On Mar 8, 2017 4:29 AM, "Joe Orton"  wrote:


Sorry, taking my time here, and I appreciate all the feedback.
Definitely happier to debate it and get it right than be lumbered with
annoying edge cases forever.

I did the refactoring in r1785943, so third iteration attached has both
 and .  I'd have been fine with either
previous iteration, but this does make sense to me.

Final call for yay/nay?


Aye!

Re: [RFC] ?

[Stefan Eissing]

+1

> Am 08.03.2017 um 11:29 schrieb Joe Orton :
> 
> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

AW: [RFC] ?

[Plüm , Rüdiger , Vodafone Group]

+1

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Joe Orton [mailto:jor...@redhat.com]
> Gesendet: Mittwoch, 8. März 2017 11:30
> An: dev@httpd.apache.org
> Betreff: Re: [RFC] ?
> 
> On Tue, Mar 07, 2017 at 11:52:17AM -0800, Jacob Champion wrote:
> > On 02/28/2017 04:32 PM, Jacob Champion wrote:
> > > I just don't like hamstringing a nice new directive with what's
> > > effectively a (rare) bug.
> >
> > (The conversation kinda died shortly after I said this. That was not
> my
> > intent -- I like this directive a lot. Whether the consensus is to
> keep the
> > corner case, or introduce a new  or , or make
> the
> > arg quotable, or whatever. I don't mean to be throwing up roadblocks.)
> 
> Sorry, taking my time here, and I appreciate all the feedback.
> Definitely happier to debate it and get it right than be lumbered with
> annoying edge cases forever.
> 
> I did the refactoring in r1785943, so third iteration attached has both
>  and .  I'd have been fine with either
> previous iteration, but this does make sense to me.
> 
> Final call for yay/nay?
> 
> Regards, Joe

Re: [RFC] ?

[Joe Orton]

On Tue, Mar 07, 2017 at 11:52:17AM -0800, Jacob Champion wrote:
> On 02/28/2017 04:32 PM, Jacob Champion wrote:
> > I just don't like hamstringing a nice new directive with what's
> > effectively a (rare) bug.
> 
> (The conversation kinda died shortly after I said this. That was not my
> intent -- I like this directive a lot. Whether the consensus is to keep the
> corner case, or introduce a new  or , or make the
> arg quotable, or whatever. I don't mean to be throwing up roadblocks.)

Sorry, taking my time here, and I appreciate all the feedback.  
Definitely happier to debate it and get it right than be lumbered with 
annoying edge cases forever.

I did the refactoring in r1785943, so third iteration attached has both 
 and .  I'd have been fine with either 
previous iteration, but this does make sense to me.

Final call for yay/nay?

Regards, Joe
Index: server/config.c
===
--- server/config.c (revision 1785938)
+++ server/config.c (working copy)
@@ -2668,6 +2668,16 @@
 printf("  %s\n", ap_loaded_modules[n]->name);
 }
 
+AP_DECLARE(int) ap_exists_directive(apr_pool_t *p, const char *name)
+{
+char *lname = apr_pstrdup(p, name);
+
+ap_str_tolower(lname);
+
+return ap_config_hash &&
+apr_hash_get(ap_config_hash, lname, APR_HASH_KEY_STRING) != NULL;
+}
+
 AP_DECLARE(void *) ap_retained_data_get(const char *key)
 {
 void *retained;
Index: server/core.c
===
--- server/core.c   (revision 1785943)
+++ server/core.c   (working copy)
@@ -2838,6 +2838,17 @@
 return (apr_stat(, relative, 0, cmd->pool) == APR_SUCCESS);
 }
 
+static int test_ifdirective_section(cmd_parms *cmd, const char *arg)
+{
+return ap_exists_directive(cmd->temp_pool, arg);
+}
+
+static int test_ifsection_section(cmd_parms *cmd, const char *arg)
+{
+const char *name = apr_pstrcat(cmd->temp_pool, "<", arg, NULL);
+return ap_exists_directive(cmd->temp_pool, name);
+}
+
 /* httpd.conf commands... beginning with the  business */
 
 static const char *virtualhost_section(cmd_parms *cmd, void *dummy,
@@ -4456,6 +4467,12 @@
 AP_INIT_TAKE1("

Re: [RFC] ?

[Jacob Champion]

On 02/28/2017 04:32 PM, Jacob Champion wrote:

I just don't like hamstringing a nice new directive with what's
effectively a (rare) bug.


(The conversation kinda died shortly after I said this. That was not my 
intent -- I like this directive a lot. Whether the consensus is to keep 
the corner case, or introduce a new  or , or 
make the arg quotable, or whatever. I don't mean to be throwing up 
roadblocks.)


--Jacob

Re: [RFC] ?

[William A Rowe Jr]

On Tue, Feb 28, 2017 at 5:57 PM, Jacob Champion  wrote:
> On 02/27/2017 03:19 AM, Joe Orton wrote:
>>
>> On Wed, Feb 22, 2017 at 10:00:08PM +0100, Yann Ylavic wrote:
>>>
>>> On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton  wrote:

 (b) for  match both "foo" and ">>
>>>
>>> I'd vote for this, it's very unlikely that some day we want to add a
>>> directive called VirtualHost or If (w/o the leading '<') which may
>>> conflict here, so it shouldn't hurt.
>>
>>
>> I'm fine with that, I'll commit like this unless anybody else has strong
>> opinions.
>
>
> mod_lua (in trunk at least) apparently ships both a '' and 'LuaXXX'
> version of several directives. It wouldn't surprise me to find that other
> third-party modules have a "block version" of a normal directive with the
> same name. I'm kind of -0.5 to making the two collide.
>
> Is there a good reason that quoting the argument to a block gives a syntax
> error? Can we fix that instead?

As much as we all suck at naming things...

What about  vs. ?

(And deliberately circumvent anyone using 

Re: [RFC] ?

[Jacob Champion]

On 02/28/2017 04:09 PM, Eric Covener wrote:

But even if it wasn't, you'd also have to be interested in one being
available when the other isn't, for it to affect 


Right. My concern is mostly for the following situation:

- module author provides a ModuleDirective in v1
- author realizes that a block version of said directive would make a 
lot of sense

- author releases  in v2
- everyone eventually figures out, after wailing and gnashing of teeth, 
that they can't use  to differentiate between the two


I definitely don't think this will be common. I just don't like 
hamstringing a nice new directive with what's effectively a (rare) bug.


--Jacob

Re: [RFC] ?

[Eric Covener]

On Tue, Feb 28, 2017 at 6:57 PM, Jacob Champion  wrote:
> mod_lua (in trunk at least) apparently ships both a '' and 'LuaXXX'
> version of several directives. It wouldn't surprise me to find that other
> third-party modules have a "block version" of a normal directive with the
> same name. I'm kind of -0.5 to making the two collide.

I think it would still be pretty rare.

But even if it wasn't, you'd also have to be interested in one being
available when the other isn't, for it to affect 
-- 
Eric Covener
cove...@gmail.com

Re: [RFC] ?

[Jacob Champion]

On 02/27/2017 03:19 AM, Joe Orton wrote:

On Wed, Feb 22, 2017 at 10:00:08PM +0100, Yann Ylavic wrote:

On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton  wrote:

(b) for  match both "foo" and "

Re: [RFC] ?

[Joe Orton]

On Wed, Feb 22, 2017 at 10:00:08PM +0100, Yann Ylavic wrote:
> On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton  wrote:
> > (b) for  match both "foo" and " 
> I'd vote for this, it's very unlikely that some day we want to add a
> directive called VirtualHost or If (w/o the leading '<') which may
> conflict here, so it shouldn't hurt.

I'm fine with that, I'll commit like this unless anybody else has strong 
opinions.

Regards, Joe

Index: server/config.c
===
--- server/config.c (revision 1784534)
+++ server/config.c (working copy)
@@ -2668,6 +2668,24 @@
 printf("  %s\n", ap_loaded_modules[n]->name);
 }
 
+AP_DECLARE(int) ap_exists_directive(apr_pool_t *p, const char *name)
+{
+char *lname;
+
+if (!ap_config_hash)
+return 0;
+
+lname = apr_pstrdup(p, name);
+ap_str_tolower(lname);
+
+if (apr_hash_get(ap_config_hash, lname, APR_HASH_KEY_STRING) != NULL)
+return 1;
+
+/* Try '<'-prefixed form. */
+return apr_hash_get(ap_config_hash, apr_pstrcat(p, "<", lname, NULL), 
+APR_HASH_KEY_STRING) != NULL;
+ }
+
 AP_DECLARE(void *) ap_retained_data_get(const char *key)
 {
 void *retained;
Index: include/http_config.h
===
--- include/http_config.h   (revision 1784534)
+++ include/http_config.h   (working copy)
@@ -992,6 +992,15 @@
 AP_DECLARE(void) ap_show_directives(void);
 
 /**
+ * Returns non-zero if a configuration directive of the given name has
+ * been registered by a module at the time of calling.
+ * @param p Temporary pool
+ * @param name Directive name to match, case-insensitively, either
+ * directly or against '<'-prefixed container form.
+ */
+AP_DECLARE(int) ap_exists_directive(apr_pool_t *p, const char *name);
+
+/**
  * Show the preloaded module names.  Used for httpd -l.
  */
 AP_DECLARE(void) ap_show_modules(void);
Index: server/core.c
===
--- server/core.c   (revision 1784534)
+++ server/core.c   (working copy)
@@ -2894,6 +2894,46 @@
 }
 }
 
+
+static const char *start_ifdirective(cmd_parms *cmd, void *dummy, const char 
*arg)
+{
+const char *endp;
+int defined;
+int not = 0;
+
+endp = ap_strrchr_c(arg, '>');
+if (endp == NULL) {
+return unclosed_directive(cmd);
+}
+
+arg = apr_pstrmemdup(cmd->temp_pool, arg, endp - arg);
+
+if (arg[0] == '!') {
+not = 1;
+arg++;
+}
+
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
+defined = ap_exists_directive(cmd->temp_pool, arg);
+if ((!not && defined) || (not && !defined)) {
+ap_directive_t *parent = NULL;
+ap_directive_t *current = NULL;
+const char *retval;
+
+retval = ap_build_cont_config(cmd->pool, cmd->temp_pool, cmd,
+  , , "

Re: [RFC] ?

[Yann Ylavic]

On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton  wrote:
>
> It actually only works like:
>
>
>
> which is a bit ugly. Quoting the argument is a syntax error. Not sure
> how best to handle this.
>
> (b) for  match both "foo" and "
> (In core.c the start_if* code is mostly common across all the functions
> and I think can be factored out, so it's possible to make core.c
> simpler/smaller net of even two more container directives.)

+1


Regards,
Yann.

Re: [RFC] ?

[Eric Covener]

On Wed, Feb 22, 2017 at 8:43 AM, William A Rowe Jr  wrote:
> I was more concerned about our support for ...
> I'd really like to see mod_version go away in 2.next and force
> the availability of that feature so that .conf authors are assured
> of it's presence moving forwards.

+1

-- 
Eric Covener
cove...@gmail.com

Re: [RFC] ?

[William A Rowe Jr]

On Wed, Feb 22, 2017 at 1:04 AM, Nick Kew  wrote:
> On Tue, 2017-02-21 at 21:58 +, Joe Orton wrote:
>
>> Any reason  is a bad idea, so we can do that more cleanly
>> (... in a couple of decades time)?
>
> One reason it might be a very bad idea: user confusion!
>
> I'm thinking of the track record of  here.
> Our support fora are full of users who have seen it in
> default/shipped config and docs, and treat it as some
> magic incantation they need.  They end up with a problem
> "why doesn't Foo work?", which they bring to our fora
> after many hours of tearing their hair.  The usual answer:
> Get rid of all the  crap, to stop suppressing
> the error message you need!

That speaks to our docs/conf/* tree, right? Not the existence
of the  directive ... I'm guessing you don't support
eliminating that feature in the future?

I was more concerned about our support for ...
I'd really like to see mod_version go away in 2.next and force
the availability of that feature so that .conf authors are assured
of it's presence moving forwards.

An issue is that this is needed to let users devs toggle specific
tests based on patch level. Right now, testing requires a backport,
which doesn't vary by the httpd version, and only rarely varies
by .  This proposal makes introducing the tests
upon adding a feature to trunk painless; the test is accessible
from the moment the directive is backported.

If you want to propose an " considered harmful"
caution in the docs (which we can borrow or point to for the
 docs) ... that could be helpful. It often indicates
that the user's conf was not thought out, and that it is subject
to unexpected behavior changes if a module is loaded or
commented out. That doesn't mean these serve no purpose.

Re: [RFC] ?

[Joe Orton]

On Tue, Feb 21, 2017 at 02:28:52PM -0800, Jacob Champion wrote:
> I haven't tried your patch yet, but from inspection it looks like you'd have
> to do something like this if you're looking for a :
> 
> 
> ...
> 
> (Note the missing closing angle bracket in the argument.) Assuming I've read
> that correctly, should we add some sugar to allow "" to be fully
> bracketed in the argument?

It actually only works like:

   

which is a bit ugly. Quoting the argument is a syntax error. Not sure 
how best to handle this.

(a) ignore the problem, i.e. allow above syntax
(b) for  match both "foo" and "

Re: [RFC] ?

[Stefan Eissing]

Neat! +1

> Am 21.02.2017 um 22:58 schrieb Joe Orton :
> 
> For cases like HttpProtocolOptions where a new directive is introduced 
> to multiple active branches simultaneously, it gets awkward to use 
>  to write conf files which use the new directive but are 
> compatible across multiple versions.
> 
> Triggered by a conversation with a user, but also e.g. see current test 
> suite t/conf/extra.conf.in which breaks for 2.4 releases older than 
> 2.4.25 with:
> 
>  = 2.2.32>
>
>  DocumentRoot @SERVERROOT@/htdocs/
>  HttpProtocolOptions Strict Require1.0 RegisteredMethods
> 
> Any reason  is a bad idea, so we can do that more cleanly 
> (... in a couple of decades time)?
> 
> Regards, Joe
> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: [RFC] ?

[Nick Kew]

On Tue, 2017-02-21 at 21:58 +, Joe Orton wrote:

> Any reason  is a bad idea, so we can do that more cleanly 
> (... in a couple of decades time)?

One reason it might be a very bad idea: user confusion!

I'm thinking of the track record of  here.
Our support fora are full of users who have seen it in
default/shipped config and docs, and treat it as some
magic incantation they need.  They end up with a problem
"why doesn't Foo work?", which they bring to our fora
after many hours of tearing their hair.  The usual answer:
Get rid of all the  crap, to stop suppressing
the error message you need!

-- 
Nick Kew

Re: [RFC] ?

[Reindl Harald]

Am 21.02.2017 um 23:24 schrieb Eric Covener:

On Tue, Feb 21, 2017 at 5:20 PM, Reindl Harald  wrote:



Am 21.02.2017 um 22:58 schrieb Joe Orton:


For cases like HttpProtocolOptions where a new directive is introduced
to multiple active branches simultaneously, it gets awkward to use
 to write conf files which use the new directive but are
compatible across multiple versions.

Triggered by a conversation with a user, but also e.g. see current test
suite t/conf/extra.conf.in which breaks for 2.4 releases older than
2.4.25 with:

  = 2.2.32>

  DocumentRoot @SERVERROOT@/htdocs/
  HttpProtocolOptions Strict Require1.0 RegisteredMethods

Any reason  is a bad idea, so we can do that more cleanly
(... in a couple of decades time)?



you need to wrap that at least in  since mod_version is not
mandatory and httpd if unforgiving for unknown options

for the same reason the dance below is needed


 
  Require all denied
 
 
  Order deny,allow
  Deny from All
 


 
  Order deny,allow
  Deny from all
 
 = 2.4>
  Require all denied
 



Kind of weird to keep the 

in *this* example maybe, in general the "= 2.4>" can be more 
specific like "= 2.4>" because there where options added in 
2.4.x releases which would stop httpd on older minor versions and 
especially in conext of LTS distributions you don't always know which 
features are really in the 2.4.x-distr


SSLCompression
Available in httpd 2.4.3 and later

so you can write a config which is safe for any httpd but chain it to 
recent features if available and *if* mod_version is available

Re: [RFC] ?

[Jacob Champion]

On 02/21/2017 01:58 PM, Joe Orton wrote:

Any reason  is a bad idea, so we can do that more cleanly
(... in a couple of decades time)?


I like it! It would be really useful for running bisections... once 
we're far enough in the future, that is. I currently have to comment out 
portions of the test config (including the one you pointed out, 
incidentally).


I haven't tried your patch yet, but from inspection it looks like you'd 
have to do something like this if you're looking for a :



...

(Note the missing closing angle bracket in the argument.) Assuming I've 
read that correctly, should we add some sugar to allow "" to 
be fully bracketed in the argument?


--Jacob

Re: [RFC] ?

[Eric Covener]

On Tue, Feb 21, 2017 at 5:20 PM, Reindl Harald  wrote:
>
>
> Am 21.02.2017 um 22:58 schrieb Joe Orton:
>>
>> For cases like HttpProtocolOptions where a new directive is introduced
>> to multiple active branches simultaneously, it gets awkward to use
>>  to write conf files which use the new directive but are
>> compatible across multiple versions.
>>
>> Triggered by a conversation with a user, but also e.g. see current test
>> suite t/conf/extra.conf.in which breaks for 2.4 releases older than
>> 2.4.25 with:
>>
>>   = 2.2.32>
>> 
>>   DocumentRoot @SERVERROOT@/htdocs/
>>   HttpProtocolOptions Strict Require1.0 RegisteredMethods
>>
>> Any reason  is a bad idea, so we can do that more cleanly
>> (... in a couple of decades time)?
>
>
> you need to wrap that at least in  since mod_version is not
> mandatory and httpd if unforgiving for unknown options
>
> for the same reason the dance below is needed
>
> 
>  
>   Require all denied
>  
>  
>   Order deny,allow
>   Deny from All
>  
> 
> 
>  
>   Order deny,allow
>   Deny from all
>  
>  = 2.4>
>   Require all denied
>  
> 

Kind of weird to keep the 

Re: [RFC] ?

[Reindl Harald]

Am 21.02.2017 um 22:58 schrieb Joe Orton:

For cases like HttpProtocolOptions where a new directive is introduced
to multiple active branches simultaneously, it gets awkward to use
 to write conf files which use the new directive but are
compatible across multiple versions.

Triggered by a conversation with a user, but also e.g. see current test
suite t/conf/extra.conf.in which breaks for 2.4 releases older than
2.4.25 with:

  = 2.2.32>

  DocumentRoot @SERVERROOT@/htdocs/
  HttpProtocolOptions Strict Require1.0 RegisteredMethods

Any reason  is a bad idea, so we can do that more cleanly
(... in a couple of decades time)?


you need to wrap that at least in  since mod_version is not 
mandatory and httpd if unforgiving for unknown options


for the same reason the dance below is needed


 
  Require all denied
 
 
  Order deny,allow
  Deny from All
 


 
  Order deny,allow
  Deny from all
 
 = 2.4>
  Require all denied
 

Re: [RFC] ?

[Eric Covener]

On Tue, Feb 21, 2017 at 4:58 PM, Joe Orton  wrote:
> For cases like HttpProtocolOptions where a new directive is introduced
> to multiple active branches simultaneously, it gets awkward to use
>  to write conf files which use the new directive but are
> compatible across multiple versions.
>
> Triggered by a conversation with a user, but also e.g. see current test
> suite t/conf/extra.conf.in which breaks for 2.4 releases older than
> 2.4.25 with:
>
>   = 2.2.32>
> 
>   DocumentRoot @SERVERROOT@/htdocs/
>   HttpProtocolOptions Strict Require1.0 RegisteredMethods
>
> Any reason  is a bad idea, so we can do that more cleanly
> (... in a couple of decades time)?
>
> Regards, Joe

Seems pretty neat.

[RFC] ?

[Joe Orton]

For cases like HttpProtocolOptions where a new directive is introduced 
to multiple active branches simultaneously, it gets awkward to use 
 to write conf files which use the new directive but are 
compatible across multiple versions.

Triggered by a conversation with a user, but also e.g. see current test 
suite t/conf/extra.conf.in which breaks for 2.4 releases older than 
2.4.25 with:

  = 2.2.32>

  DocumentRoot @SERVERROOT@/htdocs/
  HttpProtocolOptions Strict Require1.0 RegisteredMethods

Any reason  is a bad idea, so we can do that more cleanly 
(... in a couple of decades time)?

Regards, Joe
Index: server/config.c
===
--- server/config.c (revision 1783943)
+++ server/config.c (working copy)
@@ -2668,6 +2668,16 @@
 printf("  %s\n", ap_loaded_modules[n]->name);
 }
 
+AP_DECLARE(int) ap_exists_directive(apr_pool_t *p, const char *name)
+{
+char *lname = apr_pstrdup(p, name);
+
+ap_str_tolower(lname);
+
+return ap_config_hash &&
+apr_hash_get(ap_config_hash, lname, APR_HASH_KEY_STRING) != NULL;
+}
+
 AP_DECLARE(void *) ap_retained_data_get(const char *key)
 {
 void *retained;
Index: include/http_config.h
===
--- include/http_config.h   (revision 1783943)
+++ include/http_config.h   (working copy)
@@ -992,6 +992,12 @@
 AP_DECLARE(void) ap_show_directives(void);
 
 /**
+ * Returns non-zero if a configuration directive of the given name has
+ * been registered by a module at the time of calling.
+ */
+AP_DECLARE(int) ap_exists_directive(apr_pool_t *p, const char *name);
+
+/**
  * Show the preloaded module names.  Used for httpd -l.
  */
 AP_DECLARE(void) ap_show_modules(void);
Index: server/core.c
===
--- server/core.c   (revision 1783943)
+++ server/core.c   (working copy)
@@ -2894,6 +2894,46 @@
 }
 }
 
+
+static const char *start_ifdirective(cmd_parms *cmd, void *dummy, const char 
*arg)
+{
+const char *endp;
+int defined;
+int not = 0;
+
+endp = ap_strrchr_c(arg, '>');
+if (endp == NULL) {
+return unclosed_directive(cmd);
+}
+
+arg = apr_pstrmemdup(cmd->temp_pool, arg, endp - arg);
+
+if (arg[0] == '!') {
+not = 1;
+arg++;
+}
+
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
+defined = ap_exists_directive(cmd->temp_pool, arg);
+if ((!not && defined) || (not && !defined)) {
+ap_directive_t *parent = NULL;
+ap_directive_t *current = NULL;
+const char *retval;
+
+retval = ap_build_cont_config(cmd->pool, cmd->temp_pool, cmd,
+  , , "

Re: [PATCH] on TRACE & RFC compliance

[Joe Orton]

Thanks a lot, all.  I dropped the last sentence and pushed to trunk & 
2.4.x.   r1750750 & r1750752

Re: [PATCH] on TRACE & RFC compliance

[Ruediger Pluem]

On 06/29/2016 02:44 PM, Eric Covener wrote:
> On Wed, Jun 29, 2016 at 8:08 AM, William A Rowe Jr  
> wrote:
>> The wording change seems fine to me, I'd actually be fine with simply
>> dropping
>> your last sentence entirely. Our config defaults speak for themselves.
> 
> 
> I think the last sentence is a little strong too.  People are just
> going to disable it based on commercial scanners anyway.
> 

+1

Regards

Rüdiger

Re: [PATCH] on TRACE & RFC compliance

[Eric Covener]

On Wed, Jun 29, 2016 at 8:08 AM, William A Rowe Jr  wrote:
> The wording change seems fine to me, I'd actually be fine with simply
> dropping
> your last sentence entirely. Our config defaults speak for themselves.


I think the last sentence is a little strong too.  People are just
going to disable it based on commercial scanners anyway.

-- 
Eric Covener
cove...@gmail.com

Re: [PATCH] on TRACE & RFC compliance

[William A Rowe Jr]

The wording change seems fine to me, I'd actually be fine with simply
dropping
your last sentence entirely. Our config defaults speak for themselves.

On Wed, Jun 29, 2016 at 6:55 AM, Joe Orton  wrote:

> We had a couple of people complaining about the language around TRACE in
> the docs, which say disabling TRACE "makes your server noncompliant", a
> claim I found hard to support.
>
> All methods but HEAD and GET are defined as OPTIONAL, so I'm not sure
> how this is true, am I missing something?
>
> https://tools.ietf.org/html/rfc2616#section-5.1.1
> https://tools.ietf.org/html/rfc7231#section-4.1
>
> Is that choice of words just to scare people off?  IIRC there are some
> pretty strong opinions on this; attached is how I'd change it.
>

[PATCH] on TRACE & RFC compliance

[Joe Orton]

We had a couple of people complaining about the language around TRACE in 
the docs, which say disabling TRACE "makes your server noncompliant", a 
claim I found hard to support.
  
All methods but HEAD and GET are defined as OPTIONAL, so I'm not sure 
how this is true, am I missing something?

https://tools.ietf.org/html/rfc2616#section-5.1.1
https://tools.ietf.org/html/rfc7231#section-4.1

Is that choice of words just to scare people off?  IIRC there are some 
pretty strong opinions on this; attached is how I'd change it.
Index: docs/manual/mod/core.xml
===
--- docs/manual/mod/core.xml(revision 1750619)
+++ docs/manual/mod/core.xml(working copy)
@@ -4532,16 +4532,20 @@
 Finally, for testing and diagnostic purposes only, request
 bodies may be allowed using the non-compliant TraceEnable
 extended directive.  The core (as an origin server) will
-restrict the request body to 64k (plus 8k for chunk headers if
+restrict the request body to 64Kb (plus 8Kb for chunk headers if
 Transfer-Encoding: chunked is used).  The core will
 reflect the full headers and all chunk headers with the response
 body.  As a proxy server, the request body is not restricted to 64k.
 
 Note
-Despite claims to the contrary, TRACE is not
-a security vulnerability, and there is no viable reason for
-it to be disabled. Doing so necessarily makes your server
-noncompliant.
+
+Despite claims to the contrary, enabling the TRACE
+method does not expose any security vulnerability in Apache httpd.
+The TRACE method is defined by the HTTP/1.1
+specification and implementations are expected to support it.
+Leaving TRACE enabled is strongly recommended for all
+deployments of Apache httpd.
+
 
 
 

Re: RFC 7230..7235 Parsing Conformance?

[Jacob Champion]

On 05/17/2016 02:53 PM, William A Rowe Jr wrote:
> (Note that HT is a CTL, right, so it appears to be doubly excluded, no?)
> CHAR is US-ASCII 0-127.

I noticed that too... It seems odd, but it's water under the bridge now,
I guess.

> The characters missing above from tchar are '"', '(', ')', ',', '/',
> ':', ';', '<', '=', '>', '?', '@', '[', '\', ']', '{', '}' which
> corresponds to this delimiter list, and to the RFC2616 list. VCHAR is
> clearly US-ASCII 20-7E, possibly includes tab. (Tabs are visible spacing.)

RFC 7230 defers to RFC 5234 [1] for VCHAR:

>  VCHAR  =  %x21-7E
> ; visible (printing) characters

So neither spaces nor tabs by my reading.

> So my concerns may have been unfounded, but reviewing the new spec
> against implementation still seems prudent.

+1 to that.

Getting back to your original question, then: if there are any
differences that do come up, I personally think it would be nice if the
new rules were used by default in the next major release, but
case-by-case consideration would probably be appropriate for now.

--Jacob

[1] https://tools.ietf.org/html/rfc5234#appendix-B.1

Re: RFC 7230..7235 Parsing Conformance?

[William A Rowe Jr]

Based on Jason's question...

On Tue, May 17, 2016 at 1:31 PM, William A Rowe Jr 
wrote:

> On Tue, May 17, 2016 at 1:00 PM, Julian Reschke 
> wrote:
>
>> On 2016-05-17 19:01, Graham Leggett wrote:
>>
>>> On 17 May 2016, at 6:43 PM, William A Rowe Jr 
>>> wrote:
>>>
>>> Wondering what other contributors are thinking on this topic.

 We have a number of changes in the ABNF grammar between
 RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be
 an entirely RFC723x generation server, and drop all support for
 RFC2616?

 Do we want to backport these changes to 2.4.x? If so, what
 mechanism do we want to toggle the behavior of the server
 between 2616 and 7230..7235?

 We can presume a small performance hit in any conditional
 operation, especially when those decisions apply to tight parsing
 loop. Toggling between two different parser implementations would
 probably be a bit more efficient than conditionals within a parser
 itself.

>>>
>>> Can you give some examples to get a sense of the extent of this?
>>>
>> +1 to the question; I'd like to see examples as well...
>>
>> I believe we only changed the ABNF when we came to the conclusion that
>> the old one was incorrect, or did not reflect what implementations do in
>> practice.
>>
>
> One of the more significant is the change to token,
> https://tools.ietf.org/html/rfc2616#section-2.2
>
>  token  = 1*
>
>
   separators = "(" | ")" | "<" | ">" | "@"
  | "," | ";" | ":" | "\" | <">
  | "/" | "[" | "]" | "?" | "="
  | "{" | "}" | SP | HT


(Note that HT is a CTL, right, so it appears to be doubly excluded, no?)
CHAR is US-ASCII 0-127.


> vs https://tools.ietf.org/html/rfc7230#section-3.2.6
>
>  token  = 1*tchar
>
>  tchar  = "!" / "#" / "$" / "%" / "&" / "'" / "*"
> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
> / DIGIT / ALPHA
> ; any VCHAR, except delimiters
>
>
  "Delimiters are chosen
   from the set of US-ASCII visual characters not allowed in a token
   (DQUOTE and "(),/:;<=>?@[\]{}")."


The characters missing above from tchar are '"', '(', ')', ',', '/', ':',
';', '<', '=', '>', '?', '@', '[', '\', ']', '{', '}' which corresponds to
this delimiter list, and to the RFC2616 list. VCHAR is clearly US-ASCII
20-7E, possibly includes tab. (Tabs are visible spacing.)

So my concerns may have been unfounded, but reviewing the new spec against
implementation still seems prudent. As I come across specifics we can
discuss those, sorry for my confusion.

Re: RFC 7230..7235 Parsing Conformance?

[Jacob Champion]

On 05/17/2016 11:31 AM, William A Rowe Jr wrote:
> One of the more significant is the change to token,
> https://tools.ietf.org/html/rfc2616#section-2.2
> 
> token = 1*
> 
> 
> vs https://tools.ietf.org/html/rfc7230#section-3.2.6
> 
>  token  = 1*tchar
> 
>  tchar  = "!" / "#" / "$" / "%" / "&" / "'" / "*"
> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
> / DIGIT / ALPHA
> ; any VCHAR, except delimiters

Is there a difference between these, other than that the first
definition is subtractive and the second is additive? I did a quick
check through an ASCII table and they seemed to be equivalent to me.

--Jacob

Re: RFC 7230..7235 Parsing Conformance?

[Eric Covener]

On Tue, May 17, 2016 at 9:43 AM, William A Rowe Jr  wrote:
> Do we want to backport these changes to 2.4.x? If so, what
> mechanism do we want to toggle the behavior of the server
> between 2616 and 7230..7235?

I would piggyback it on the "HttpProtocol" strict stuff that also
needs backporting.

Re: RFC 7230..7235 Parsing Conformance?

[William A Rowe Jr]

On Tue, May 17, 2016 at 1:00 PM, Julian Reschke 
wrote:

> On 2016-05-17 19:01, Graham Leggett wrote:
>
>> On 17 May 2016, at 6:43 PM, William A Rowe Jr 
>> wrote:
>>
>> Wondering what other contributors are thinking on this topic.
>>>
>>> We have a number of changes in the ABNF grammar between
>>> RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be
>>> an entirely RFC723x generation server, and drop all support for
>>> RFC2616?
>>>
>>> Do we want to backport these changes to 2.4.x? If so, what
>>> mechanism do we want to toggle the behavior of the server
>>> between 2616 and 7230..7235?
>>>
>>> We can presume a small performance hit in any conditional
>>> operation, especially when those decisions apply to tight parsing
>>> loop. Toggling between two different parser implementations would
>>> probably be a bit more efficient than conditionals within a parser
>>> itself.
>>>
>>
>> Can you give some examples to get a sense of the extent of this?
>>
> +1 to the question; I'd like to see examples as well...
>
> I believe we only changed the ABNF when we came to the conclusion that the
> old one was incorrect, or did not reflect what implementations do in
> practice.
>

One of the more significant is the change to token,
https://tools.ietf.org/html/rfc2616#section-2.2

 token  = 1*


vs https://tools.ietf.org/html/rfc7230#section-3.2.6

 token  = 1*tchar

 tchar  = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; any VCHAR, except delimiters


This has a lot of tangential effects. My plan was to begin auditing
the code against spec and begin assembling patches. My question
in the note above is how we will generally handle the shift from one
spec to the next, and what we will promise our users (use 2.next/3.0
for conformance? Use 2.4 to retain 2616 behavior?)

Re: RFC 7230..7235 Parsing Conformance?

[Julian Reschke]

On 2016-05-17 19:01, Graham Leggett wrote:

On 17 May 2016, at 6:43 PM, William A Rowe Jr  wrote:


Wondering what other contributors are thinking on this topic.

We have a number of changes in the ABNF grammar between
RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be
an entirely RFC723x generation server, and drop all support for
RFC2616?

Do we want to backport these changes to 2.4.x? If so, what
mechanism do we want to toggle the behavior of the server
between 2616 and 7230..7235?

We can presume a small performance hit in any conditional
operation, especially when those decisions apply to tight parsing
loop. Toggling between two different parser implementations would
probably be a bit more efficient than conditionals within a parser
itself.


Can you give some examples to get a sense of the extent of this?

Regards,
Graham


+1 to the question; I'd like to see examples as well...

I believe we only changed the ABNF when we came to the conclusion that 
the old one was incorrect, or did not reflect what implementations do in 
practice.


Best regards, Julian

Re: RFC 7230..7235 Parsing Conformance?

[Graham Leggett]

On 17 May 2016, at 6:43 PM, William A Rowe Jr  wrote:

> Wondering what other contributors are thinking on this topic.
> 
> We have a number of changes in the ABNF grammar between
> RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be 
> an entirely RFC723x generation server, and drop all support for 
> RFC2616? 
> 
> Do we want to backport these changes to 2.4.x? If so, what
> mechanism do we want to toggle the behavior of the server
> between 2616 and 7230..7235? 
> 
> We can presume a small performance hit in any conditional 
> operation, especially when those decisions apply to tight parsing 
> loop. Toggling between two different parser implementations would
> probably be a bit more efficient than conditionals within a parser
> itself.

Can you give some examples to get a sense of the extent of this?

Regards,
Graham
—

RFC 7230..7235 Parsing Conformance?

[William A Rowe Jr]

Wondering what other contributors are thinking on this topic.

We have a number of changes in the ABNF grammar between
RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be
an entirely RFC723x generation server, and drop all support for
RFC2616?

Do we want to backport these changes to 2.4.x? If so, what
mechanism do we want to toggle the behavior of the server
between 2616 and 7230..7235?

We can presume a small performance hit in any conditional
operation, especially when those decisions apply to tight parsing
loop. Toggling between two different parser implementations would
probably be a bit more efficient than conditionals within a parser
itself.

Fwd: RFC 7804 on Salted Challenge Response HTTP Authentication Mechanism

[Roy T. Fielding]

For folks looking for a new feature to develop,

Roy


> Begin forwarded message:
> 
> From: rfc-edi...@rfc-editor.org
> Subject: RFC 7804 on Salted Challenge Response HTTP Authentication Mechanism
> Date: March 9, 2016 at 11:01:55 AM PST
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> Cc: drafts-update-...@iana.org, http-a...@ietf.org, rfc-edi...@rfc-editor.org
> Reply-To: i...@ietf.org
> List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>RFC 7804
> 
>Title:  Salted Challenge Response HTTP Authentication 
>Mechanism 
>Author: A. Melnikov
>Status: Experimental
>Stream: IETF
>Date:   March 2016
>Mailbox:alexey.melni...@isode.com
>Pages:  18
>Characters: 39440
>Updates/Obsoletes/SeeAlso:   None
> 
>I-D Tag:draft-ietf-httpauth-scram-auth-15.txt
> 
>URL:https://www.rfc-editor.org/info/rfc7804
> 
>DOI:http://dx.doi.org/10.17487/RFC7804
> 
> This specification describes a family of HTTP authentication
> mechanisms called the Salted Challenge Response Authentication
> Mechanism (SCRAM), which provides a more robust authentication
> mechanism than a plaintext password protected by Transport Layer
> Security (TLS) and avoids the deployment obstacles presented by
> earlier TLS-protected challenge response authentication mechanisms.
> 
> This document is a product of the Hypertext Transfer Protocol Authentication 
> Working Group of the IETF.
> 
> 
> EXPERIMENTAL: This memo defines an Experimental Protocol for the
> Internet community.  It does not specify an Internet standard of any
> kind. Discussion and suggestions for improvement are requested.
> Distribution of this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr]

On Sep 6, 2015 8:09 AM, "Kaspar Brand"  wrote:
>
> On 05.09.2015 13:06, Tim Bannister wrote:
> > It's not just conventional browsers. I think automated / embedded
> > HTTP clients will also benefit from stapling, either because
> > networking filters would block a conversation between the client and
> > the CA's OCSP responder, or the extra latency from using conventional
> > OCSP is a problem.
>
> That hope is mostly futile:

Kaspar,

It might help to pause here and ask what your hope or aspiration is, here.
I am reading a lot of 'no, not that' in your messages, but very little
'this instead would improve the status quo.'. Please share so we aren't
talking past one another

Yours,

Bill

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 05.09.2015 13:06, Tim Bannister wrote:
> It's not just conventional browsers. I think automated / embedded
> HTTP clients will also benefit from stapling, either because
> networking filters would block a conversation between the client and
> the CA's OCSP responder, or the extra latency from using conventional
> OCSP is a problem.

That hope is mostly futile: OpenSSL e.g., presumably quite popular
for implementing such clients, does not include any readily available
support for enabling OCSP checking in client mode. And even if a library
has some sort of knob for turning it on (Sun^WOracle's CertPath provider
e.g.), you'll mostly find that they don't handle stapled responses.
Consider yourself happy if a client at least does some sort of hostname
verification (see https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf for
further background, the situation didn't change fundamentally since then).

> For another example of a non-interactive application implementing
> OCSP, look at the Exim mail transfer agent (which can be both client
> and server).

SMTP with STARTTLS isn't a useful example, sorry... it's opportunistic
encryption only in the best case, and for MTA communications, DANE-EE
(https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/) looks
like a more promising approach.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Reindl Harald]

Am 06.09.2015 um 15:06 schrieb Kaspar Brand:

Taking into account that OCSP responders from the big players are
running on fairly robust infrastructure these days (cf. the sr.symcd.com
example, aka ocsp.verisign.net, aka ocsp.ws.symantec.com.edgekey.net),
I'm not buying the "OCSP is unreliable" statement in this wholesale form.


"fairly robust" don't change the fact that they would be a perfect DDOS 
target and so an attacker would point one botnet to your server and the 
other to the matching OCSP responder - not to forget how many sites you 
can DDOS in case of clients would enforce OCSP and hard-fail


currently they are not a target for such attacks



signature.asc
Description: OpenPGP digital signature

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 05.09.2015 12:53, Ben Laurie wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand  wrote:
>> I'm also very sceptical that a higher percentage of handshakes with
>> stapled responses (how much exactly?) will lead browser vendors to
>> switch to hard fail - as the test-sspev.verisign.com example from my
>> previous message shows, they could do this for EV today already (even
>> Chrome tries querying the OCSP responder in this case). But none of them
>> does, often due to the fear of losing market share when being too strict
>> in enforcing TLS security (cf. the case of RC4 banning).
>>
> 
> I don't know why you think your example shows that - the reason browsers
> don't hard fail is because OCSP (or any out of band communication) is
> unreliable.

Unreliable in what sense, or for what reason? Due to OCSP responders
being unreachable, being unable to handle the load, serving flawed
responses (like the recent hiccup mentioned in
https://twitter.com/GSSystemAlerts/status/634418637835669504), or...?
Only the second point can be addressed by stapling, as it simply
switches to another method for transmitting the response to the client.

> So that either means you fail for sites that are actually
> perfectly OK, or you allow an attacker to override revocation (by blocking
> OCSP).
> 
>  This is why browsers are pushing for OCSP stapling, not because of speed.

Taking into account that OCSP responders from the big players are
running on fairly robust infrastructure these days (cf. the sr.symcd.com
example, aka ocsp.verisign.net, aka ocsp.ws.symantec.com.edgekey.net),
I'm not buying the "OCSP is unreliable" statement in this wholesale form.

Even assuming that, say, 90% of all handshakes would include stapled
responses one day, I'm pretty sure that browsers would come up with
other arguments as to why they can't enforce hard-fail. Or perhaps in
one or two years, they want everybody to switch to using short-lived
certs without OCSP (because "revocation doesn't work" anyway), at which
point the "let's get OCSP stapling universally deployed" exercise would
become moot.

> Certificate Transparency faces the same problem, which is why it only
> exists as an in-band mechanism.
> 
> Blocking stapling (and presumably you will also object to CT for similar
> reasons) is hurting security.

CT is a completely separate topic, but for the sake of completeness:
yes, I would object to enabling such a feature in httpd by default, as
long as it triggers outgoing connections on the server. That isn't the
case for being able to serve SCTs, however: all it takes is
httpd/mod_ssl 2.4.8 or later compiled against OpenSSL 1.0.2a or later,
an appropriate "BEGIN SERVERINFO FOR..." file and an "SSLOpenSSLConfCmd
ServerInfoFile ..." directive in the config (no outgoing connectivity on
the server needed, neither permanently nor temporarily).

> You've argued that there's no point switching on stapling because browsers
> won't pay attention to OCSP anyway. That is not true. They don't pay
> attention to OCSP because it is unreliable. If stapling were widely
> deployed, then it would be possible to switch on hard fail.

Again, the "OCSP is unreliable" statement is just your current claim
(unless you can provide real-world measurements showing things like "30%
of all OCSP queries fail due to timeouts", "50% of all OCSP checks take
more than 3 seconds" or similar). Having used Firefox with
security.OCSP.require=true for extended periods of time, I do not agree
with the overall assessment of OCSP being unreliable.

> Leaving it to admins makes no sense to me - most admins are not acquainted
> with the detailed reasons for/against stapling, and are not in a position
> to make an informed decision.

That's what our documentation is for. Just asserting that admins
are too dumb to understand and instead decide on their behalf is an
attitude I strongly dislike. Apache httpd is not the same sort of
software like browsers for the big (and probably often clueless) masses,
where that approach might have its justification.

> Someone has to choose the default, and IMO
> the ASF should always default to "more secure".

Pretty muddy ground - "more secure" in what sense exactly? A server not
being dependent on outgoing connectivity for its day-to-day operations
is typically more secure than one which regularly needs to fetch data
from the outside world.

And if stapling is really making servers "more secure", why are
www.google.com, mail.google.com or drive.google.com still not providing
stapled responses as of today? (same is true for other high-traffic
sites like Twitter or FB, JFTR)

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 05.09.2015 14:23, Jeff Trawick wrote:
> On 09/04/2015 10:59 AM, Kaspar Brand wrote:
>>> 1. The default configuration should not trigger unsolicited outgoing
>>> queries to untrusted systems, for both a) and b), that's how I would put it.
> 
> Re: "unsolicited":
> 
> Key words/phrases from the other end of the continuum: "unexpected by 
> many", "responder obtained from explicitly configured certificate"

The other end of the continuum would be "explicitly requested", in my
view. "unsolicited" = "not explicitly requested", that's what I intended
to say (and "explicitly" referring to something like "manually enabling
a directive").

> The unexpected aspect could be helped by a [notice] message at startup 
> indicating that an OCSP responder will be contacted for N certificates 
> due to the directive.  (If there is only one, an alternate message could 
> be displayed with the actual responder URL; we couldn't do that for 
> arbitrary numbers.)

IMO, not a sufficient method for justifying a "default on" setting
(configuring a Base64 encoded certificate blob through
SSLCertificateFile doesn't amount to explicitly configuring a responder
URI).

> Re: "untrusted":
> 
> The certificate and its content are untrusted in general?

Technically speaking, as long as mod_ssl doesn't validate the cert file
against a set of (locally configured) trust anchors, the complete file
is to be considered untrusted. An admin could have received a "fake
reply" for his CSR, where the public key perfectly matches the private
key, but the contents are bogus otherwise. Sure, he would most likely
realize this quite soon after having configured the cert and trying to
connect to his own server, but essentially, I wouldn't consider the
contents pointed to by an SSLCertificateFile directive as trusted.

> The content 
> is trusted but the responder URL is not what/who it seems? (I wasn't 
> sure where you were leading when you alluded to this in prior 
> correspondence.)

X.509v3 certs can have all sorts of "useful" extensions, and I wouldn't
consider all this information automatically trusted just because it's
signed by the CA (take the OU field in the subject DN as an example:
most CAs will have disclaimers stating that these fields are basically
"unverified").

With the OCSP URI in particular, an additional aspect of "untrusted" is
that resolving its IP address(es) relies on the DNS, i.e. a component
which can't be considered trusted when it is queried for records of
third-party domains.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Ben Laurie]

On Sat, 5 Sep 2015 at 09:32 Kaspar Brand  wrote:

> On 04.09.2015 17:54, Rob Stradling wrote:
> > Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> > enabled.  Browsers aren't likely to start hard-failing by default until
> > that % is a lot higher.
> >
> > The vast majority of the servers that have OCSP stapling enabled are
> > running IIS.  I claim that this is due to the fact that IIS enables OCSP
> > stapling by default.
>
> The relevant metric is the percentage of (initial) TLS handshakes with
> stapled responses, not so much the percentage of servers with stapling
> enabled. Judging from Mozilla's telemetry data for Firefox 39 and 40,
> that percentage is still below 15%, and enabling stapling in an httpd
> config file which gets used by a very small number of Apache httpd admins
> (as opposed to those settings which go out to the world via [1] or [2])
> doesn't look like a very effective way of achieving the goal of making
> that percentage "a lot higher".
>
> I'm also very sceptical that a higher percentage of handshakes with
> stapled responses (how much exactly?) will lead browser vendors to
> switch to hard fail - as the test-sspev.verisign.com example from my
> previous message shows, they could do this for EV today already (even
> Chrome tries querying the OCSP responder in this case). But none of them
> does, often due to the fear of losing market share when being too strict
> in enforcing TLS security (cf. the case of RC4 banning).
>

I don't know why you think your example shows that - the reason browsers
don't hard fail is because OCSP (or any out of band communication) is
unreliable. So that either means you fail for sites that are actually
perfectly OK, or you allow an attacker to override revocation (by blocking
OCSP).

 This is why browsers are pushing for OCSP stapling, not because of speed.

Certificate Transparency faces the same problem, which is why it only
exists as an in-band mechanism.

Blocking stapling (and presumably you will also object to CT for similar
reasons) is hurting security.

You've argued that there's no point switching on stapling because browsers
won't pay attention to OCSP anyway. That is not true. They don't pay
attention to OCSP because it is unreliable. If stapling were widely
deployed, then it would be possible to switch on hard fail.

Leaving it to admins makes no sense to me - most admins are not acquainted
with the detailed reasons for/against stapling, and are not in a position
to make an informed decision. Someone has to choose the default, and IMO
the ASF should always default to "more secure".


> > I think you've misunderstood the "speed, speed, speed" argument.
> >
> > If an OCSP response is delivered via stapling, then there's no need for
> > the browser to block the TLS handshake whilst it obtains an OCSP
> > response directly from the CA's OCSP responder.
>
> No, I didn't misunderstand. That's very much the essence of the "speed,
> speed, speed" argument - "our browser must be able to complete every TLS
> handshake in under 100 ms"... even if for a specific server, it's just
> one TLS handshake per day where it really matters.
>
> > Stapling provides a noticeable speedup even if the browser never caches
> > OCSP responses.
>
> Fairly hypothetical point - I'm not aware of any common browser which
> would use a cert validation library without an OCSP cache.
>
> Kaspar
>
>
> [1] https://git.centos.org/blob/rpms!httpd.git/c7/SOURCES!ssl.conf
>
> [2]
> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apache2/trusty/view/head:/debian/config-dir/sites-available/default-ssl
>

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Tim Bannister]

On 5 Sep 2015, at 11:53, Ben Laurie  wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand  wrote:
>> On 04.09.2015 17:54, Rob Stradling wrote:
>>> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling 
>>> enabled.  Browsers aren't likely to start hard-failing by default until 
>>> that % is a lot higher.
> 
> …the reason browsers don't hard fail is because OCSP (or any out of band 
> communication) is unreliable. So that either means you fail for sites that 
> are actually perfectly OK, or you allow an attacker to override revocation 
> (by blocking OCSP).
…
> Blocking stapling (and presumably you will also object to CT for similar 
> reasons) is hurting security.
> 
> You've argued that there's no point switching on stapling because browsers 
> won't pay attention to OCSP anyway. That is not true. They don't pay 
> attention to OCSP because it is unreliable. If stapling were widely deployed, 
> then it would be possible to switch on hard fail.

It's not just conventional browsers. I think automated / embedded HTTP clients 
will also benefit from stapling, either because  networking filters would block 
a conversation between the client and the CA's OCSP responder, or the extra 
latency from using conventional OCSP is a problem.

For another example of a non-interactive application implementing OCSP, look at 
the Exim mail transfer agent (which can be both client and server).

-- 
Tim Bannister – is...@c8h10n4o2.org.uk

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 04.09.2015 17:54, Rob Stradling wrote:
> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> enabled.  Browsers aren't likely to start hard-failing by default until
> that % is a lot higher.
> 
> The vast majority of the servers that have OCSP stapling enabled are
> running IIS.  I claim that this is due to the fact that IIS enables OCSP
> stapling by default.

The relevant metric is the percentage of (initial) TLS handshakes with
stapled responses, not so much the percentage of servers with stapling
enabled. Judging from Mozilla's telemetry data for Firefox 39 and 40,
that percentage is still below 15%, and enabling stapling in an httpd
config file which gets used by a very small number of Apache httpd admins
(as opposed to those settings which go out to the world via [1] or [2])
doesn't look like a very effective way of achieving the goal of making
that percentage "a lot higher".

I'm also very sceptical that a higher percentage of handshakes with
stapled responses (how much exactly?) will lead browser vendors to
switch to hard fail - as the test-sspev.verisign.com example from my
previous message shows, they could do this for EV today already (even
Chrome tries querying the OCSP responder in this case). But none of them
does, often due to the fear of losing market share when being too strict
in enforcing TLS security (cf. the case of RC4 banning).

> I think you've misunderstood the "speed, speed, speed" argument.
> 
> If an OCSP response is delivered via stapling, then there's no need for
> the browser to block the TLS handshake whilst it obtains an OCSP
> response directly from the CA's OCSP responder.

No, I didn't misunderstand. That's very much the essence of the "speed,
speed, speed" argument - "our browser must be able to complete every TLS
handshake in under 100 ms"... even if for a specific server, it's just
one TLS handshake per day where it really matters.

> Stapling provides a noticeable speedup even if the browser never caches
> OCSP responses.

Fairly hypothetical point - I'm not aware of any common browser which
would use a cert validation library without an OCSP cache.

Kaspar


[1] https://git.centos.org/blob/rpms!httpd.git/c7/SOURCES!ssl.conf

[2] 
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apache2/trusty/view/head:/debian/config-dir/sites-available/default-ssl

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On 09/04/2015 10:59 AM, Kaspar Brand wrote:

On 02.09.2015 01:54, Jeff Trawick wrote:

On 08/30/2015 02:30 AM, Kaspar Brand wrote:

today's situation, because this assessment misses the fact that with the
current RFC-6066-based implementation, stapling can't fully achieve the
goal of obviating OCSP queries for the clients - all publicly trusted
CAs use hierarchies with at least two tiers these days, so effectively
RFC 6961 support would be needed.

I plead ignorance, but I don't see that "can't fully achieve" is a blocker.

It's not a blocker, sure, but on the other hand, the benefit of enabling
stapling by default isn't that big either - as long as browsers don't
hard-fail when OCSP information isn't available. The "speed, speed,
speed" argument (coming mostly from the browser vendors) isn't too
convincing to me neither, as OCSP replies are usually cached for one
or two days, and the typical user doesn't connect to thousands of
new/different SSL sites per day.


Is there a synopsis of which browsers support it for which types of
certificates?

I don't think so, and it's probably also kind of a moving target. Chrome
"supports" it for DV and OV as well - it will include a status_request
extension in the TLS handshake by default -, but what I meant with
"enforces" is that it won't care if there's no stapled response
(Google's ceterum censeo used to be "Revocation doesn't work", which in
2012 lead to their implementation of CRL sets where the code is public,
but "the process by which they are generated is not",
https://dev.chromium.org/Home/chromium-security/crlsets).

For EV certs, the browser behavior is more uniform, though strict hard
fail enforcement still isn't happening - for testing purposes, try
this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
and point the browser to
https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
With strict revocation checking enforced, no browser should ever render
any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
Test Page" (but most do when revocation information is not available,
although some at least show warnings or downgrade the UI to non-EV).


The motivation for putting it in trunk is so that the next release has
stapling enabled in the default configurations, which essentially means
that in some number of years (2-3?  I dunno) there will be a
faster-growing number of httpd instances that have OCSP stapling enabled.

Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
several years, I assume. What I don't like with this approach in any
case, however, is that we as the devs decide on behalf of the admins,
instead of letting them make an informed decision. I' really arguing
in favor of something like this in httpd-ssl.conf.in:

--- snip ---
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#  Server Certificate and Private Key:
#  ...
SSLCertificateFile "conf/server.crt"
SSLCertificateKeyFile "conf/server.key"

#  OCSP Stapling:
#  For SSL certificates which include an OCSP responder URI, mod_ssl
#  can include revocation status information for the server's own
#  certificate in the TLS handshake. Enabling this option requires
#  outgoing connectivity to the CA's OCSP responder (usually running
#  running on port 80, use "openssl x509 -in server.crt -text" to
#  determine the exact URI), so this option is not enabled by default.
#  The responder will be queried with the interval configured
#  via SSLStaplingStandardCacheTimeout. For EV SSL certificates
#  in particular, enabling this option is recommended/useful.
#SSLUseStapling On
--- snip ---

(i.e., move the SSLUseStapling directive closer to the cert settings,
and make people aware of the outgoing connections this will trigger)


Part of what makes the 2.4.x tangent is confusing is that sometimes your
objections seem to be qualified on the assumption that 2.4.x would be
updated.  Can we please drop 2.4.x from this conversation?

Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
basic question remains, though: is it acceptable that configuring an SSL
certificate potentially triggers outgoing OCSP requests in mod_ssl,
without having been explicitly instructed to do so by an admin? My view
is still the same as in November 2014: admins should opt in for this
feature, not be forced to opt out.


   It's also for this reason that I'm not in favor of a global
"SSLUseStapling On", it should really be configured on a per-vhost basis.

I don't follow.  What does that help?  With which attack vector does
that improve the situation?

The point I was trying to make is that stapling is a per-certificate
feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
it would be best if the admin becomes aware of it when configuring the cert.


While I find the "n

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 02.09.2015 01:54, Jeff Trawick wrote:
> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>> today's situation, because this assessment misses the fact that with the
>> current RFC-6066-based implementation, stapling can't fully achieve the
>> goal of obviating OCSP queries for the clients - all publicly trusted
>> CAs use hierarchies with at least two tiers these days, so effectively
>> RFC 6961 support would be needed.
> I plead ignorance, but I don't see that "can't fully achieve" is a blocker.

It's not a blocker, sure, but on the other hand, the benefit of enabling
stapling by default isn't that big either - as long as browsers don't
hard-fail when OCSP information isn't available. The "speed, speed,
speed" argument (coming mostly from the browser vendors) isn't too
convincing to me neither, as OCSP replies are usually cached for one
or two days, and the typical user doesn't connect to thousands of
new/different SSL sites per day.

> Is there a synopsis of which browsers support it for which types of 
> certificates?

I don't think so, and it's probably also kind of a moving target. Chrome
"supports" it for DV and OV as well - it will include a status_request
extension in the TLS handshake by default -, but what I meant with
"enforces" is that it won't care if there's no stapled response
(Google's ceterum censeo used to be "Revocation doesn't work", which in
2012 lead to their implementation of CRL sets where the code is public,
but "the process by which they are generated is not",
https://dev.chromium.org/Home/chromium-security/crlsets).

For EV certs, the browser behavior is more uniform, though strict hard
fail enforcement still isn't happening - for testing purposes, try
this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
and point the browser to
https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
With strict revocation checking enforced, no browser should ever render
any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
Test Page" (but most do when revocation information is not available,
although some at least show warnings or downgrade the UI to non-EV).

> The motivation for putting it in trunk is so that the next release has 
> stapling enabled in the default configurations, which essentially means 
> that in some number of years (2-3?  I dunno) there will be a 
> faster-growing number of httpd instances that have OCSP stapling enabled.

Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
several years, I assume. What I don't like with this approach in any
case, however, is that we as the devs decide on behalf of the admins,
instead of letting them make an informed decision. I' really arguing
in favor of something like this in httpd-ssl.conf.in:

--- snip ---
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#  Server Certificate and Private Key:
#  ...
SSLCertificateFile "conf/server.crt"
SSLCertificateKeyFile "conf/server.key"

#  OCSP Stapling:
#  For SSL certificates which include an OCSP responder URI, mod_ssl
#  can include revocation status information for the server's own
#  certificate in the TLS handshake. Enabling this option requires
#  outgoing connectivity to the CA's OCSP responder (usually running
#  running on port 80, use "openssl x509 -in server.crt -text" to
#  determine the exact URI), so this option is not enabled by default.
#  The responder will be queried with the interval configured
#  via SSLStaplingStandardCacheTimeout. For EV SSL certificates
#  in particular, enabling this option is recommended/useful.
#SSLUseStapling On
--- snip ---

(i.e., move the SSLUseStapling directive closer to the cert settings,
and make people aware of the outgoing connections this will trigger)

> Part of what makes the 2.4.x tangent is confusing is that sometimes your 
> objections seem to be qualified on the assumption that 2.4.x would be 
> updated.  Can we please drop 2.4.x from this conversation?

Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
basic question remains, though: is it acceptable that configuring an SSL
certificate potentially triggers outgoing OCSP requests in mod_ssl,
without having been explicitly instructed to do so by an admin? My view
is still the same as in November 2014: admins should opt in for this
feature, not be forced to opt out.

>>   It's also for this reason that I'm not in favor of a global
>> "SSLUseStapling On", it should really be configured on a per-vhost basis.
> 
> I don't follow.  What does that help?  With which attack vector does 
> that improve the situation?

The point I was trying to make is that stapling is a per-certificate
feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
it would be be

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Rob Stradling]

On 04/09/15 15:59, Kaspar Brand wrote:
> On 02.09.2015 01:54, Jeff Trawick wrote:
>> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>>> today's situation, because this assessment misses the fact that with the
>>> current RFC-6066-based implementation, stapling can't fully achieve the
>>> goal of obviating OCSP queries for the clients - all publicly trusted
>>> CAs use hierarchies with at least two tiers these days, so effectively
>>> RFC 6961 support would be needed.
>> I plead ignorance, but I don't see that "can't fully achieve" is a blocker.
> 
> It's not a blocker, sure, but on the other hand, the benefit of enabling
> stapling by default isn't that big either - as long as browsers don't
> hard-fail when OCSP information isn't available.

Kaspar,

Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
enabled.  Browsers aren't likely to start hard-failing by default until
that % is a lot higher.

The vast majority of the servers that have OCSP stapling enabled are
running IIS.  I claim that this is due to the fact that IIS enables OCSP
stapling by default.

If we don't enable OCSP stapling by default in httpd, how are we going
to increase that % ?

> The "speed, speed,
> speed" argument (coming mostly from the browser vendors) isn't too
> convincing to me neither, as OCSP replies are usually cached for one
> or two days, and the typical user doesn't connect to thousands of
> new/different SSL sites per day.

I think you've misunderstood the "speed, speed, speed" argument.

If an OCSP response is delivered via stapling, then there's no need for
the browser to block the TLS handshake whilst it obtains an OCSP
response directly from the CA's OCSP responder.

Stapling provides a noticeable speedup even if the browser never caches
OCSP responses.

>> Is there a synopsis of which browsers support it for which types of 
>> certificates?
> 
> I don't think so, and it's probably also kind of a moving target. Chrome
> "supports" it for DV and OV as well - it will include a status_request
> extension in the TLS handshake by default -, but what I meant with
> "enforces" is that it won't care if there's no stapled response
> (Google's ceterum censeo used to be "Revocation doesn't work", which in
> 2012 lead to their implementation of CRL sets where the code is public,
> but "the process by which they are generated is not",
> https://dev.chromium.org/Home/chromium-security/crlsets).
> 
> For EV certs, the browser behavior is more uniform, though strict hard
> fail enforcement still isn't happening - for testing purposes, try
> this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
> and point the browser to
> https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
> With strict revocation checking enforced, no browser should ever render
> any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
> Test Page" (but most do when revocation information is not available,
> although some at least show warnings or downgrade the UI to non-EV).
> 
>> The motivation for putting it in trunk is so that the next release has 
>> stapling enabled in the default configurations, which essentially means 
>> that in some number of years (2-3?  I dunno) there will be a 
>> faster-growing number of httpd instances that have OCSP stapling enabled.
> 
> Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
> several years, I assume. What I don't like with this approach in any
> case, however, is that we as the devs decide on behalf of the admins,
> instead of letting them make an informed decision. I' really arguing
> in favor of something like this in httpd-ssl.conf.in:
> 
> --- snip ---
> #   SSL Engine Switch:
> #   Enable/Disable SSL for this virtual host.
> SSLEngine on
> 
> #  Server Certificate and Private Key:
> #  ...
> SSLCertificateFile "conf/server.crt"
> SSLCertificateKeyFile "conf/server.key"
> 
> #  OCSP Stapling:
> #  For SSL certificates which include an OCSP responder URI, mod_ssl
> #  can include revocation status information for the server's own
> #  certificate in the TLS handshake. Enabling this option requires
> #  outgoing connectivity to the CA's OCSP responder (usually running
> #  running on port 80, use "openssl x509 -in server.crt -text" to
> #  determine the exact URI), so this option is not enabled by default.
> #  The responder will be queried with the interval configured
> #  via SSLStaplingStandardCacheTimeout. For EV SSL certificates
> #  in particular, enabling this option is recommended/useful.
> #SSLUseStapling On
> --- snip ---
> 
> (i.e., m

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On 08/30/2015 02:30 AM, Kaspar Brand wrote:

On 28.08.2015 19:27, Jeff Trawick wrote:

For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to enable.

I have some doubts whether "widely accepted" is an accurate summary of
today's situation, because this assessment misses the fact that with the
current RFC-6066-based implementation, stapling can't fully achieve the
goal of obviating OCSP queries for the clients - all publicly trusted
CAs use hierarchies with at least two tiers these days, so effectively
RFC 6961 support would be needed.

I plead ignorance, but I don't see that "can't fully achieve" is a blocker.


  And given that the most popular
browser only enforces revocation checking for EV certificates (certainly
less than 10% of all SSL certs out there), the benefit of turning on
stapling for DV/OV certs by default is not so apparent either.


Is there a synopsis of which browsers support it for which types of 
certificates?




What wasn't mentioned in the original RFC [1], and what I'm still
wondering about, is the primary motivation for enabling it on trunk?


The motivation for putting it in trunk is so that the next release has 
stapling enabled in the default configurations, which essentially means 
that in some number of years (2-3?  I dunno) there will be a 
faster-growing number of httpd instances that have OCSP stapling enabled.


Admins can of course enable it now, but people don't bother until 
something like SSLLabs starts dinging configurations that don't have it on.



  As
I wrote in my reply at that time, changing the default in trunk will
hardly help in getting broader real-world testing results.


For now, it hardly helps.  As we approach a release and start talking 
about it and having alphas and betas, it helps a lot more because more 
than the same 20 people are trying it out.



  If the
plan is to propose a backport to 2.4.x soon afterwards, however, then I
would certainly oppose unless systematic coverage for OCSP stapling is
added to the test framework (enabling a feature by default in a GA
release for which there is not a single test is a no go, IMO).


The point about adding tests is good.

I find this 2.4.x tangent disorienting, but maybe that's just me. (And 
even if 2.4.x default configs were changed, it would affect hardly 
anyone.  The people who build from source and just start using the 
latest configs every time probably aren't in control of many aspects of 
their system anyway.  Building and installing the normal way leaves you 
with the same configuration.)


Part of what makes the 2.4.x tangent is confusing is that sometimes your 
objections seem to be qualified on the assumption that 2.4.x would be 
updated.  Can we please drop 2.4.x from this conversation?





Also, strictly speaking, the default config does not have SSL enabled
anyway, and after manually enabling it OCSP responses won't be fetched
unless a certificate is configured which references an OCSP responder.

It should be worth mentioning that the OCSP URI in a server cert is to
be considered untrusted, as mod_ssl does not validate its own cert at
startup.


I would think that the problem is if the hostname doesn't point where it 
is supposed to point, so the I/O can't be allowed to stall and mod_ssl 
and OpenSSL have to avoid assuming the data is well-formed.  Besides 
that, the admin and the browser own the rest.



  It's also for this reason that I'm not in favor of a global
"SSLUseStapling On", it should really be configured on a per-vhost basis.


I don't follow.  What does that help?  With which attack vector does 
that improve the situation?





While I find the "not make accidental outgoing connections" argument
compelling (though perhaps with a different word than "accidental") the
server already takes actions that cause outgoing connections to services
not explicitly configured (DNS), and these occasionally cause problems.

Are you referring to queries when doing PTR lookups for connecting
clients? I think that's one of the very reasons why "HostnameLookups
Off" was chosen for extra/httpd-default.conf.


Not HostnameLookups; resolving ServerName at startup (configured or 
defaulted).



Is there a principle at stake which could be followed consistently across
disparate features in how the server behaves a) with compiled in defaults
and minimal config, or b) with default/recommended config?

The default configuration should not trigger unsolicited outgoing
queries to untrusted systems, for both a) and b), that's how I would
put it.


Admin configures a certificate that has a domain name of attacker in the 
responder URI?  DNS entry for domain name in responder URI is taken over 
to point to attacker?



  Additionally, features enabled by default need to have sufficient
cove

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On 08/29/2015 08:10 PM, William A Rowe Jr wrote:


On Aug 29, 2015 1:49 PM, "Jeff Trawick" > wrote:

>
> On 08/28/2015 04:17 PM, Tim Bannister wrote:
>>
>> Jeff Trawick > wrote:
>>>
>>>
>>> As of now there's still a veto on my suggestion of enabling 
stapling by

>>> default in the httpd trunk config.
>>
>> Would that default need to be backported to 2.4.x?
>
>
> "need"?  No; 2.4.x is a separate consideration.
>
>
>> If it can be on by default for trunk/2.5.x, and off by default in 
earlier releases, this should surprise very few users.

>>
>> People upgrading from an older release could get a mild surprise, 
but at the same time if you upgrade from 2.4.x to 2.5.x then surprises 
aren't all that surprising.

>>
>> Overall I think the big question mark is around backport to 2.4.x 
rather than the change to httpd trunk.


I thought this question was largely resolved, that we wouldn't want 
subversion updates to break a users config unexpectedly.  POLS.


You know this, but just for completeness: 
Subversion-update-breaks-users-config is when compiled-in default 
behavior changes, which could affect configurations with no stapling 
directive, which wasn't proposed even for trunk.

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 28.08.2015 19:27, Jeff Trawick wrote:
 For one, it is appropriate for the default config is there to enable
 practices which are reasonable in most situations, and OCSP Stapling is
 widely accepted as an appropriate feature for HTTP servers to enable.

I have some doubts whether widely accepted is an accurate summary of
today's situation, because this assessment misses the fact that with the
current RFC-6066-based implementation, stapling can't fully achieve the
goal of obviating OCSP queries for the clients - all publicly trusted
CAs use hierarchies with at least two tiers these days, so effectively
RFC 6961 support would be needed. And given that the most popular
browser only enforces revocation checking for EV certificates (certainly
less than 10% of all SSL certs out there), the benefit of turning on
stapling for DV/OV certs by default is not so apparent either.

What wasn't mentioned in the original RFC [1], and what I'm still
wondering about, is the primary motivation for enabling it on trunk? As
I wrote in my reply at that time, changing the default in trunk will
hardly help in getting broader real-world testing results. If the
plan is to propose a backport to 2.4.x soon afterwards, however, then I
would certainly oppose unless systematic coverage for OCSP stapling is
added to the test framework (enabling a feature by default in a GA
release for which there is not a single test is a no go, IMO).

 Also, strictly speaking, the default config does not have SSL enabled
 anyway, and after manually enabling it OCSP responses won't be fetched
 unless a certificate is configured which references an OCSP responder.

It should be worth mentioning that the OCSP URI in a server cert is to
be considered untrusted, as mod_ssl does not validate its own cert at
startup. It's also for this reason that I'm not in favor of a global
SSLUseStapling On, it should really be configured on a per-vhost basis.

 While I find the not make accidental outgoing connections argument
 compelling (though perhaps with a different word than accidental) the
 server already takes actions that cause outgoing connections to services
 not explicitly configured (DNS), and these occasionally cause problems.

Are you referring to queries when doing PTR lookups for connecting
clients? I think that's one of the very reasons why HostnameLookups
Off was chosen for extra/httpd-default.conf.

 Is there a principle at stake which could be followed consistently across
 disparate features in how the server behaves a) with compiled in defaults
 and minimal config, or b) with default/recommended config?

The default configuration should not trigger unsolicited outgoing
queries to untrusted systems, for both a) and b), that's how I would
put it. Additionally, features enabled by default need to have sufficient
coverage in the test framework.

 If enabling stapling were more closely tied in the configuration language
 to configuring a certificate, which with SSLUseStapling On is the user
 action that makes mod_ssl talk to a responder, would that help the end
 user?  (Controlling stapling parameters on a per-certificate basis is
 valuable anyway since you can have multiple certificates per vhost,
 possibly with different responders.)

It's not very common to configure multiple certs for a single vhost, I
guess - mainly due to the single-chain-only limitation in OpenSSL up to
1.0.1. I wouldn't put too much effort into making it a per-certificate
setting (seems relatively complex to implement, at least at first glance).

Kaspar

[1] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201410.mbox/%3CCAKUrXK6k01WGqF8z6F3YBNbanbTaOSHbbzwSi2O3H3u03_mvUw%40mail.gmail.com%3E

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Brian Smith]

Kaspar Brand httpd-dev.2...@velox.ch wrote:

 On 28.08.2015 19:27, Jeff Trawick wrote:
  For one, it is appropriate for the default config is there to enable
  practices which are reasonable in most situations, and OCSP Stapling is
  widely accepted as an appropriate feature for HTTP servers to enable.

 I have some doubts whether widely accepted is an accurate summary of
 today's situation, because this assessment misses the fact that with the
 current RFC-6066-based implementation, stapling can't fully achieve the
 goal of obviating OCSP queries for the clients - all publicly trusted
 CAs use hierarchies with at least two tiers these days, so effectively
 RFC 6961 support would be needed.


This is not true. In the case of Firefox, and I believe Chrome, it was
decided that the website is responsible for delivering the OCSP response
(via stapling) for the end-entity, and the browser is responsible for
getting the revocation info for the intermediates *in some unspecified
way*. In practice, that way is CRLSets. I think MSIE is or has also started
moving to that model.

In particular, browser makers aren't interested in RFC 6961 because of it
is a poor performance trade-off and also never implemented.



 And given that the most popular
 browser only enforces revocation checking for EV certificates (certainly
 less than 10% of all SSL certs out there), the benefit of turning on
 stapling for DV/OV certs by default is not so apparent either.


This is a chicken-and-egg problem. The proposed Must-Staple feature makes
OCSP useful. Obviously Must-Staple only works if the server staples the
response. Conversely, without Must-Staple, OCSP is useless in browsers.


 What wasn't mentioned in the original RFC [1], and what I'm still
 wondering about, is the primary motivation for enabling it on trunk?


The main motivation for OCSP stapling is to demonstrate that OCSP stapling
works in a widespread way, so that browsers can start implementing the
Must-Staple feature and gather useful metrics about the effects, including
any possible negative side effects.


 As I wrote in my reply at that time, changing the default in trunk will
 hardly help in getting broader real-world testing results.


It has to be changed on Trunk before it can be changed anywhere else, right?



 If the
 plan is to propose a backport to 2.4.x soon afterwards, however, then I
 would certainly oppose unless systematic coverage for OCSP stapling is
 added to the test framework (enabling a feature by default in a GA
 release for which there is not a single test is a no go, IMO).


I agree.

And, to be perfectly honest, there are a lot of things that can go wrong
with OCSP stapling and I've yet to see an implementation without a serious
flaw.


 It should be worth mentioning that the OCSP URI in a server cert is to
 be considered untrusted, as mod_ssl does not validate its own cert at
 startup.


Using that argument, it isn't safe to use the server's end-entity
certificate either, because it hasn't been checked for validity. In
particular, it hasn't been checked for revocation! The Heartbleed
vulnerability had such a huge impact partially because there was no
**effective** and easy-to-use way for servers to revoke certificates. We
need to find a solution to revocation and I think that Apache enabling OCSP
stapling by default is the next step towards a solution.


 The default configuration should not trigger unsolicited outgoing
 queries to untrusted systems, for both a) and b), that's how I would
 put it.


Look at IIS, which has been doing OCSP stapling by default, without
significant problems, for many years now. Has anybody really been harmed by
IIS's default? I don't think so. I think this is an instance of the perfect
being the enemy of the good.


 Additionally, features enabled by default need to have sufficient
 coverage in the test framework.


Again, I agree.

In case it would be helpful: When I was at Mozilla, my team created a new
certificate verification library for Firefox. That includes a complete
implementation of OCSP verification. It also includes a small test suite
for OCSP verification. We intentionally licensed it under the Apache 2.0
license so that Apache could use the code, if Apache wants to use it. If
nothing else, the OCSP tests [3] might be a useful model for Apache's tests.

After I left Mozilla, I separated out the implementation from Firefox's
repository and made it available on GitHub: [1]. I spent some time making
that code work with OpenSSL in a branch [2].

[1] https://github.com/briansmith/mozillapkix
[2] https://github.com/briansmith/mozillapkix/tree/feature/openssl
[3]
https://github.com/briansmith/mozillapkix/blob/master/test/gtest/pkixocsp_VerifyEncodedOCSPResponse.cpp

Cheers,
Brian
-- 
https://briansmith.org/

Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 29.08.2015 17:56, olli hauer wrote:
 On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote:
 Thanks for the detailed explanation. So yes OCSP stapling is really
 beneficial if it is possible for the server admin to set it up. But
 it likely requires additional configuration steps outside of httpd
 to make the OCSP responder reachable (like firewall clearances) and
 leads to otherwise strange slow responses if this is not
 prepared. Another obstacle with the current stapling code is that
 the connection to the OCSP responder of the CA needs to happen
 directly and cannot be done via a proxy. Hence I agree with Kaspar
 that it should be off by default.
 
 
 Not tested, but looking at the mod_ssl doc it seems
 SSLStaplingForceURL can be used to proxy requests to the OCSP
 responder(s)
 
 http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingforceurl

 In case SSLStaplingForceURL can be used to force OCSP requests via
 proxy it would be nice to add something like the following patch
 before enabling OCSP stapling as default.

It can't be used like this, as pointed out in [1]. Its main use is for
certs which do not include an OCSP URI at all, so configuring
SSLStaplingForceURL at the global level doesn't make much sense - you
would have to run a transparent OCSP proxy at that URL (mod_ssl will
just send plain OCSP requests to this address).

Kaspar

[1] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201411.mbox/%3C5454A1FE.6060204%40velox.ch%3E

Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[olli hauer]

On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote:
 
 
 -Ursprüngliche Nachricht-
 Von: Rob Stradling [mailto:rob.stradl...@comodo.com]
 Gesendet: Freitag, 3. Juli 2015 12:01
 An: dev@httpd.apache.org
 Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk

 On 02/07/15 19:03, Ruediger Pluem wrote:
 snip
 Just to be sure I don't miss anything. This is not about disabling
 OCSP, its about disabling OCSP stapling by default.
 Maybe I have a wrong understanding of OCSP stapling, but to me
 stapling only provides performance improvements, not
 security improvements for the client as the client still could connect
 to the OCSP URL given in the cert directly and
 get the answer from there. If the response is stabled it does not need
 to (with the same level of security) and saves
 itself a roundtrip to the OCSP server of the CA and the OCSP server of
 the CA a request to process.

 Yes, the client _could_ connect to the OCSP URL given in the cert
 directly and get the answer from there.  However, at least one major
 browser (Chrome) no longer does this, but it does process stapled OCSP
 responses.

 Even if we could ignore Chrome...
 There will always be some clients that cannot reach the CA's OCSP
 responder directly (due to connectivity issues at the client side),
 whereas the TLS servers that those clients connect to may well have
 better connectivity (and thus be able to staple OCSP responses that the
 client cannot obtain by any other means).

 Also, this isn't just about performance.  If a client contacts an OCSP
 responder directly, it reveals to the CA that it is interested in a
 particular certificate.  That's a far worse privacy leak than a TLS
 server contacting a CA's OCSP responder and revealing that it's
 interested in the status of its own certificate!!
 
 Thanks for the detailed explanation. So yes OCSP stapling is really beneficial
 if it is possible for the server admin to set it up. But it likely requires 
 additional
 configuration steps outside of httpd to make the OCSP responder reachable 
 (like firewall clearances)
 and leads to otherwise strange slow responses if this is not prepared.
 Another obstacle with the current stapling code is that the connection to the 
 OCSP responder of the
 CA needs to happen directly and cannot be done via a proxy.
 Hence I agree with Kaspar that it should be off by default.
 

Not tested, but looking at the mod_ssl doc it seems SSLStaplingForceURL can be 
used to proxy requests to the OCSP responder(s)

http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingforceurl

In case SSLStaplingForceURL can be used to force OCSP requests via proxy it 
would be nice to add something like the following patch before enabling OCSP 
stapling as default.

Index: trunk/docs/conf/extra/httpd-ssl.conf.in
===
--- trunk/docs/conf/extra/httpd-ssl.conf.in (revision 1700039)
+++ trunk/docs/conf/extra/httpd-ssl.conf.in (working copy)
@@ -114,6 +114,11 @@
 #   Seconds before invalid OCSP responses are expired from the cache
 #SSLStaplingErrorCacheTimeout 600

+#   This directive overrides the URI of an OCSP responder as obtained
+#   from the authorityInfoAccess (AIA) extension of the certificate.
+#   One potential use is when a proxy is used for retrieving OCSP queries.
+#SSLStaplingForceURL http://internal.proxy.local
+
 ##
 ## SSL Virtual Host Context
 ##

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr]

On Aug 29, 2015 1:49 PM, Jeff Trawick traw...@gmail.com wrote:

 On 08/28/2015 04:17 PM, Tim Bannister wrote:

 Jeff Trawick traw...@gmail.com wrote:


 As of now there's still a veto on my suggestion of enabling stapling by
 default in the httpd trunk config.

 Would that default need to be backported to 2.4.x?


 need?  No; 2.4.x is a separate consideration.


 If it can be on by default for trunk/2.5.x, and off by default in
earlier releases, this should surprise very few users.

 People upgrading from an older release could get a mild surprise, but at
the same time if you upgrade from 2.4.x to 2.5.x then surprises aren't all
that surprising.

 Overall I think the big question mark is around backport to 2.4.x rather
than the change to httpd trunk.

I thought this question was largely resolved, that we wouldn't want
subversion updates to break a users config unexpectedly.  POLS.

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On Mon, Jul 13, 2015 at 3:08 AM, Ruediger Pluem rpl...@apache.org wrote:



 On 07/11/2015 08:55 PM, William A Rowe Jr wrote:

  If you are suggesting we shouldn't change the compiled-in default, I can
  agree, POLS (Principal Of Least Surprise).  If you are suggesting the
 default
  config shouldn't reflect the ability to efficiently handle OCSP by
 stapling, here
  I think we would disagree.

 This something I can agree with: Leave the default compiled in to off and
 in the configuration distributed by us have it
 set to on.

 Regards

 Rüdiger


As of now there's still a veto on my suggestion of enabling stapling by
default in the httpd trunk config.  Of Kaspar's justifications, I think
this is the text that remains of his clarifying post on July 11, ignoring
the license reference:

a) by default, an HTTP server is supposed to process *incoming* requests,
not make accidental outgoing connections in addition (at least not unless
it's explicitly instructed to do so);

(I sincerely hope I haven't misconstrued the situation or missed anything
Kaspar intended.)

Those of us in favor of enabling stapling by default for those using the
default configs wouldn't have any trouble finding opposite justifications.
For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to enable.
Also, strictly speaking, the default config does not have SSL enabled
anyway, and after manually enabling it OCSP responses won't be fetched
unless a certificate is configured which references an OCSP responder.

While I find the not make accidental outgoing connections argument
compelling (though perhaps with a different word than accidental) the
server already takes actions that cause outgoing connections to services
not explicitly configured (DNS), and these occasionally cause problems.
Looking up the values of the User and Group directives can possibly invoke
one of multiple different network services depending on the system
configuration.  But I admit that's just fishing for a counter argument.

Any suggestions for breaking the apparent impasse?

Is there a principle at stake which could be followed consistently across
disparate features in how the server behaves a) with compiled in defaults
and minimal config, or b) with default/recommended config?

If enabling stapling were more closely tied in the configuration language
to configuring a certificate, which with SSLUseStapling On is the user
action that makes mod_ssl talk to a responder, would that help the end
user?  (Controlling stapling parameters on a per-certificate basis is
valuable anyway since you can have multiple certificates per vhost,
possibly with different responders.)

Thanks,

Jeff
-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Ruediger Pluem]

On 07/11/2015 08:55 PM, William A Rowe Jr wrote:

 If you are suggesting we shouldn't change the compiled-in default, I can
 agree, POLS (Principal Of Least Surprise).  If you are suggesting the default 
 config shouldn't reflect the ability to efficiently handle OCSP by stapling, 
 here 
 I think we would disagree.

This something I can agree with: Leave the default compiled in to off and in 
the configuration distributed by us have it
set to on.

Regards

Rüdiger

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 01.07.2015 14:27, Ben Laurie wrote:
 On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote:
 The fundamental objection I have to enabling stapling by default in our
 GA releases is that it would enable a phoning home feature (to the
 CA's OCSP responders) as a side effect of configuring a certificate.
 This is a setting I consider unacceptable for software published by the
 Apache HTTP Server project - the default must be opt-in, not opt-out.
 
 I've just become aware of this objection and would like to understand
 the thinking behind it. Firstly, it seems strange to call this
 phoning home, a term that _usually_ means connecting to the vendor
 of the s/w.
 
 But more importantly, what harm is there in a server connecting to the
 OCSP responders for the certificates it is serving? Why is this
 unacceptable?

It's unacceptable for at least two reasons: a) by default, an HTTP
server is supposed to process *incoming* requests, not make accidental
outgoing connections in addition (at least not unless it's explicitly
instructed to do so); b) there's no statement in our license with an
explicit caveat on such a side effect (when relying on our default
settings, configuring a site with an SSL server certificate may result
in unsolicited outgoing HTTP requests - and no, I do not want to see
our license amended by things like that).

I maintain my objection to uncommenting #SSLUseStapling On in our
default config in httpd-ssl.conf.in - and for the record, also to
changing code, be that in ssl_engine_config.c:modssl_ctx_init() or
elsewhere. Those keen on enabling it by default on behalf of the users
(because we know what is good for you) are free to lobby with the OS
vendors to have their package defaults changed.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr]

We can have a dialog about the best behavior of our default config.
However...

On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand httpd-dev.2...@velox.ch
wrote:

 On 01.07.2015 14:27, Ben Laurie wrote:
  On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch
 wrote:
  The fundamental objection I have to enabling stapling by default in our
  GA releases is that it would enable a phoning home feature (to the
  CA's OCSP responders) as a side effect of configuring a certificate.
  This is a setting I consider unacceptable for software published by the
  Apache HTTP Server project - the default must be opt-in, not opt-out.
 
  I've just become aware of this objection and would like to understand
  the thinking behind it. Firstly, it seems strange to call this
  phoning home, a term that _usually_ means connecting to the vendor
  of the s/w.
 
  But more importantly, what harm is there in a server connecting to the
  OCSP responders for the certificates it is serving? Why is this
  unacceptable?

 It's unacceptable for at least two reasons: a) by default, an HTTP
 server is supposed to process *incoming* requests, not make accidental
 outgoing connections in addition (at least not unless it's explicitly
 instructed to do so); b) there's no statement in our license with an
 explicit caveat on such a side effect (when relying on our default
 settings, configuring a site with an SSL server certificate may result
 in unsolicited outgoing HTTP requests - and no, I do not want to see
 our license amended by things like that).


Our License says nothing about accepting requests, either.  Licenses
don't express these mechanics.  They define the terms for users to
reproduce, prepare Derivative Works of, publicly display, publicly
perform,
sublicense, and distribute the work and its derivatives, and the
corresponding
patent rights as well.

A number of ASF works are servers.  A number are clients.  A number are
both clients and servers.  OCSP is hardly an accidental request, any more
than
the proxy module requests.  And in forwarding requests to https proxy
servers,
(another side effect) verifying the OCSP identity of the connected server
is
hardly an unexpected side effect, it's a characteristic of the protocol
(that
backend *server* advertised OCSP validation - stapled or indirect, and that
the *user* configured the certificate for OCSP validation).  Third party
OCSP
validation is so problematic that OCSP stapling is a blindly obvious
enhancement
that will far offset the routing configuration issues it also inspires

So your premise above is, well, outright silly.


 I maintain my objection to uncommenting #SSLUseStapling On in our
 default config in httpd-ssl.conf.in - and for the record, also to
 changing code, be that in ssl_engine_config.c:modssl_ctx_init() or
 elsewhere. Those keen on enabling it by default on behalf of the users
 (because we know what is good for you) are free to lobby with the OS
 vendors to have their package defaults changed.


You are welcome to object, and I think Ben's reply here to your thoughts
and observations, particularly your early one, since he is advocating for
this
change and this would move the dialog along to a conclusion.

Contrawise, httpd project can do the 'right thing' from our perspective,
and
the downstream distributors can correspondingly disable it.

Moreso, any enterprise so affected already is configuring httpd to their own
organization's standards and policies.

If you are suggesting we shouldn't change the compiled-in default, I can
agree, POLS (Principal Of Least Surprise).  If you are suggesting the
default
config shouldn't reflect the ability to efficiently handle OCSP by
stapling, here
I think we would disagree.

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On Sat, Jul 11, 2015 at 2:55 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 We can have a dialog about the best behavior of our default config.
 However...

 On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand httpd-dev.2...@velox.ch
 wrote:

 On 01.07.2015 14:27, Ben Laurie wrote:
  On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch
 wrote:
  The fundamental objection I have to enabling stapling by default in our
  GA releases is that it would enable a phoning home feature (to the
  CA's OCSP responders) as a side effect of configuring a certificate.
  This is a setting I consider unacceptable for software published by the
  Apache HTTP Server project - the default must be opt-in, not opt-out.
 
  I've just become aware of this objection and would like to understand
  the thinking behind it. Firstly, it seems strange to call this
  phoning home, a term that _usually_ means connecting to the vendor
  of the s/w.
 
  But more importantly, what harm is there in a server connecting to the
  OCSP responders for the certificates it is serving? Why is this
  unacceptable?

 It's unacceptable for at least two reasons: a) by default, an HTTP
 server is supposed to process *incoming* requests, not make accidental
 outgoing connections in addition (at least not unless it's explicitly
 instructed to do so); b) there's no statement in our license with an
 explicit caveat on such a side effect (when relying on our default
 settings, configuring a site with an SSL server certificate may result
 in unsolicited outgoing HTTP requests - and no, I do not want to see
 our license amended by things like that).


 Our License says nothing about accepting requests, either.  Licenses
 don't express these mechanics.  They define the terms for users to
 reproduce, prepare Derivative Works of, publicly display, publicly
 perform,
 sublicense, and distribute the work and its derivatives, and the
 corresponding
 patent rights as well.

 A number of ASF works are servers.  A number are clients.  A number are
 both clients and servers.  OCSP is hardly an accidental request, any more
 than
 the proxy module requests.  And in forwarding requests to https proxy
 servers,
 (another side effect) verifying the OCSP identity of the connected server
 is
 hardly an unexpected side effect, it's a characteristic of the protocol
 (that
 backend *server* advertised OCSP validation - stapled or indirect, and that
 the *user* configured the certificate for OCSP validation).  Third party
 OCSP
 validation is so problematic that OCSP stapling is a blindly obvious
 enhancement
 that will far offset the routing configuration issues it also inspires

 So your premise above is, well, outright silly.


 I maintain my objection to uncommenting #SSLUseStapling On in our
 default config in httpd-ssl.conf.in - and for the record, also to
 changing code, be that in ssl_engine_config.c:modssl_ctx_init() or
 elsewhere. Those keen on enabling it by default on behalf of the users
 (because we know what is good for you) are free to lobby with the OS
 vendors to have their package defaults changed.


 You are welcome to object, and I think Ben's reply here to your thoughts
 and observations, particularly your early one, since he is advocating for
 this
 change and this would move the dialog along to a conclusion.

 Contrawise, httpd project can do the 'right thing' from our perspective,
 and
 the downstream distributors can correspondingly disable it.

 Moreso, any enterprise so affected already is configuring httpd to their
 own
 organization's standards and policies.

 If you are suggesting we shouldn't change the compiled-in default, I can
 agree, POLS (Principal Of Least Surprise).  If you are suggesting the
 default
 config shouldn't reflect the ability to efficiently handle OCSP by
 stapling, here
 I think we would disagree.


Not to anyone in particular:

Contacting the OCSP responder may indeed be a surprise, and it might not
even work due to to firewall rules being effectively surprised.  (DNS was
too once upon a time.)  It does require education on the part of some
administrators.  But:

No changes discussed actually change the behavior for any non-hypothetical
configuration, since SSL is not configured by default and no existing
configurations will magically start contacting the responder.  (The more
nuanced wording of OCSP stapling by default is IFF you're using the
latest httpd default configuration files, an OCSP responder pointed to in a
certificate you configure will be utilized, unless you say otherwise.).

The config change does move the key decision point regarding this new
concept to the basic enablement of SSL.  In retrospect, it might have been
wise to enable/disable stapling on the SSLCertificateFile directive, both
for the more granular control as well as making the admin see the setting
when performing that required bit of configuration.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/