Re: [VOTE] Release Apache httpd 2.4.26 as GA

[Eric Covener]

+1 AIX/xlc/ppc64

I have two quirks to record, both are openssl / openssl 1.1 related
but given the state of my AIX system I am still +1 on the release.

 - proxy/ssl.t almost totally fails with handhsake errors between
client and origin
[Tue Jun 13 21:37:04.265062 2017] [ssl:info] [pid 15073386:tid 6169]
SSL Library Error: error:14171105:SSL
routines:tls_process_server_hello:wrong cipher returned

- There is some kind of atexit()-like issue with unloaded openssl-1.1
that causes a SIGILL at shutdown (goes away w/o mod_ssl, is not
related to signal handling thing)
.() at 0x0
exit(??) at 0x90550c0
destroy_and_exit_process(process = 0x00011001eb28,
process_exit_value = 0), line 266 in "main.c"
main(argc = 4, argv = 0x07c8), line 685 in "main.c"

Re: svn commit: r20021 - /dev/httpd/

[Jim Riggs]

I don't know that it really matters, but this guy is in there twice (in each 
CHANGES doc), once with the PR # and once without:

> +  *) mod_proxy: Allow the per-request environment variable "no-proxy" to
> + be used as an alternative to ProxyPass /path !. This is primarily
> + to set exceptions for ProxyPass specified in  context.
> +Use SetEnvIf, not SetEnv. [Eric Covener]


> +  *) mod_proxy: Allow the per-request environment variable "no-proxy" to
> + be used as an alternative to ProxyPass /path !. This is primarily
> + to set exceptions for ProxyPass specified in  context.
> + Use SetEnvIf, not SetEnv. PR 60458.  [Eric Covener]
> +

[VOTE] Release Apache httpd 2.4.26 as GA

[Jim Jagielski]

The pre-release test tarballs for Apache httpd
version 2.4.26 can be found at the usual place:

http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.26 GA.

[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.

Vote will last the normal 72 hrs.

NOTE: The *-deps are only there for convenience.

Thx!

Re: The drive for 2.4.26

[Jim Jagielski]

There was a delay in doing the T due to an issue that
was being investigated. This looks resolved now. With that,
I plan on doing a T& today at ~1:30pm (Eastern) unless someone
else wishes to RM.

Re: TTLimit directive

[Donatas Abraitis]

Hey Nick,

it must be 0, not 255. I updated it in patch attached 

Sent from my iPhone

> On 13 Jun 2017, at 13:52, Nick Kew  wrote:
> 
>> On Tue, 2017-06-13 at 11:41 +0300, Donatas Abraitis wrote:
>> 
>> I would like to propose this patchset allowing to set maximum TTL value for 
>> incoming requests. This is not a usual use case, but I'm interested (maybe 
>> others too) to have this in place. The real use case would be like this one 
>> http://blog.donatas.net/blog/2017/04/20/http-request-validation/. 
> 
> Thanks!  I'm not sure I follow your exact scenario, but it
> looks like a modest enhancement at very low cost or risk!
> 
>> TL;DR: if you want to deny requests bypassing proxy layer (in this case 
>> Apache operates as a backend). Hence set TTLimit to 1 and Apache will be 
>> able to handle requests coming almost from the local network, because 
>> packets with TTL usually come from local networks.
>> 
>> 
>> I don't know which place is the right place to put patches, but
>> original patch is here:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=61179
>> https://bz.apache.org/bugzilla/attachment.cgi?id=35048
> 
> That's exactly the right place.
> 
> At first glance, patch looks interesting, and I'm minded to
> adopt (some version of) it for trunk.  Though I think I'd
> default it to 0 (off) rather than your 255.  Any other views?
> 
> -- 
> Nick Kew
> 
> 

Re: TTLimit directive

[Nick Kew]

On Tue, 2017-06-13 at 11:41 +0300, Donatas Abraitis wrote:

> I would like to propose this patchset allowing to set maximum TTL value for 
> incoming requests. This is not a usual use case, but I'm interested (maybe 
> others too) to have this in place. The real use case would be like this one 
> http://blog.donatas.net/blog/2017/04/20/http-request-validation/. 

Thanks!  I'm not sure I follow your exact scenario, but it
looks like a modest enhancement at very low cost or risk!

> TL;DR: if you want to deny requests bypassing proxy layer (in this case 
> Apache operates as a backend). Hence set TTLimit to 1 and Apache will be able 
> to handle requests coming almost from the local network, because packets with 
> TTL usually come from local networks.
> 
> 
> I don't know which place is the right place to put patches, but
> original patch is here:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61179
> https://bz.apache.org/bugzilla/attachment.cgi?id=35048

That's exactly the right place.

At first glance, patch looks interesting, and I'm minded to
adopt (some version of) it for trunk.  Though I think I'd
default it to 0 (off) rather than your 255.  Any other views?

-- 
Nick Kew

Re: ocsp stapling improvements

[Stefan Eissing]

> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem :
> 
> 
> 
> On 06/12/2017 05:25 PM, Stefan Eissing wrote:
>> I talked to the people orignally writing our ssl OCSP code regarding
>> feedback we got from the Let's Encrypt server outage [1]. We agreed
>> that some valid points for improvement were raised and we need a 
>> discussion about what should be done about it, here.
>> 
>> I identified the following points so far:
>> 
>> 1. Hand out existing responses until expired
> 
> I guess the core mistake we do today is that we expire the entries in the 
> cache
> after SSLStaplingStandardCacheTimeout. But we should keep them in the cache 
> as long as
> they are valid (so either whats in the next update field of the response or 
> this update
> + SSLStaplingResponseMaxAge).
> Instead we should have a refresh parameter that I would set as percentage of 
> the
> expired time (so between this update and next update or as percentage of 
> already
> expired SSLStaplingResponseMaxAge). Once this refresh time is passed OCSP 
> responses
> should get refreshed by a background job (possibly implemented by 
> mod_watchdog).

+1

>> 2. Persist responses (is this just a config/default issue?)
> 
> This could become tricky given the various so cache implementations we have. 
> I could
> only think of persisting the whole cache when Apache is shutdown.

Hmm, if there is a single watchdog job fetching/updating the OCSP responses, 
we'd no
long have requests triggered by new connections in child processes, right? That
would make a file based lookup quite simple, I'd assume?

>> 3. Start update responses at server start/regular intervals
> 
> What I want to avoid is that the server "hangs" at start because of a 
> "hanging" OCSP server.
> I admit that this can happen already today on the very first SSL request with 
> stapling turned
> on, but IMHO this is a bad behavior. So either just do the stuff on a regular 
> basis in the background
> and do not staple if there is no valid OCSP response yet (I know Hanno won't 
> like that :-))
> Or have an initial (valid) OCSP response being loaded from a file during 
> startup. It would be up to
> the admin to fill this file with a valid OCSP response before it starts httpd.

The goal would be anyway, given watchdog refreshes at appropriate times, to 
always have
persisted and valid ocsp responses. Only when a new cert gets deployed, there 
would be the
chance of "missing" ocsp responses until the watchdog job can retrieve it.

If we serve the connection then without, or fail after a small grace timeout, 
will probably need to be decided by the admin.

>> 4. Use something better than HTTP/1.0 requests
> 
> What issues do we have with the HTTP/1.0 requests?

None i know of in ocsp. So, disregard this please. I take it back.

>> I think 1) should be not too complicated code changes without
>> any big restructuring. I saw Ruediger already doing some changes.
>> 
>> The reason for 2) is not clear to me. Is this just a configuration
>> issue to have a persistent cache or is our giving up privileges
>> limiting here?
>> 
>> As to 3, starting a task at server start or after a certain interval,
>> do we have some infrastructure for this? Do we need something new?
>> 
>> On 4, it seems, we lack a good http(s) client. The code we use
>> for proxying is not easily reused for new connections, or? I see
>> more need for such a thing in the near future.
>> 
>> Feedback appreciated.
> 
> Regards
> 
> Rüdiger

Re: ocsp stapling improvements

[Stefan Eissing]

> Am 13.06.2017 um 00:48 schrieb Hanno Böck :
> 
> Hi,
> 
> On Mon, 12 Jun 2017 17:25:39 +0200
> Stefan Eissing  wrote:
> 
>> 1. Hand out existing responses until expired
>> 2. Persist responses (is this just a config/default issue?)
>> 3. Start update responses at server start/regular intervals
>> 4. Use something better than HTTP/1.0 requests
> 
> 1-3 covers the important issues, I'm not sure http/1.0 is a major
> problem. Are there any problems with that / CAs that serve OCSP only
> over HTTP/1.1?
> (to be clear: certainly desirable to have a better solution here, but I
> feel that isn't the most important issue.)

Agreed.

> What I think needs also be handled:
> * There's
>  https://bz.apache.org/bugzilla/show_bug.cgi?id=59049
>  which indicates that faulty responses from the OCSP server may bring
>  the server into a faulty state from which it doesn't recover. I
>  haven't tried to reproduce this, but it certianly should be fixed as
>  well, probably just some missing error check tough.
> * Some of the existing options imho don't make any sense and should
>  default to off and maybe even be forced off (so that setting them to
>  "on" doesn't do anything). That includes SSLStaplingFakeTryLater and
>  SSLStaplingReturnResponderErrors. Unless I'm missing something I
>  don't see any situation in which stapling OCSP errors is desirable.

Will have a look.

- Stefan

> -- 
> Hanno Böck
> https://hboeck.de/
> 
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

TTLimit directive

[Donatas Abraitis]

Hi,

I would like to propose this patchset allowing to set maximum TTL
value for incoming requests. This is not a usual use case, but I'm
interested (maybe others too) to have this in place. The real use case
would be like this one
http://blog.donatas.net/blog/2017/04/20/http-request-validation/.

TL;DR: if you want to deny requests bypassing proxy layer (in this
case Apache operates as a backend). Hence set TTLimit to 1 and Apache
will be able to handle requests coming almost from the local network,
because packets with TTL usually come from local networks.

I don't know which place is the right place to put patches, but original
patch is here: https://bz.apache.org/bugzilla/show_bug.cgi?id=61179
https://bz.apache.org/bugzilla/attachment.cgi?id=35048

-- 
Donatas