Test suite and OpenSSL 1.1.1

[Rainer Jung]

Am 19.10.2018 um 23:31 schrieb Yann Ylavic:

Could not make the test suite framework work with 1.1.1 (cpan -u didn't help).
Although the ssl tests report SUCCESS, httpd actually timeouts on
SSL_peek() (as already reported).


Indeed I checked my test suite logs and until now all tests only used 
TLS 1.2. But what works for me now with TLS 1.3 is:


- small fix in TestSSLCA.pm (r1844389), otherwise the geneated 
t/conf/ssl/ssl.conf always contains "SSLProtocol all -TLSv1.3" instead 
of "all" (unless you specifiy -sslproto explicitly).


- Net::SSLeay 1.86_06 tag from Github 
https://github.com/radiator-software/p5-net-ssleay.git. Added "-ldl 
-pthread" to OTHERLDFLAGS in Makefile. It contains the plumbing needed 
for some new 1.1.1 APIs.


- IO/Socket/SSL.pm recent version 2.060 plus patch 
https://github.com/noxxi/p5-io-socket-ssl/commit/e96b1c9e394011de4ee181cfa42b8021796bf7d4.patch 
(probably not needed) plus anti-hang patch to call 
Net::SSLeay::CTX_set_post_handshake_auth()


--- IO/Socket/SSL.pm.orig  2018-08-15 18:03:29.0 +
+++ IO/Socket/SSL.pm   2018-09-19 16:37:46.450281000 +
@@ -2594,6 +2594,10 @@
"Failed to load key from file (no PEM or DER)");
}

+if ($havecert && $havekey && 
Net::SSLeay::OPENSSL_VERSION_NUMBER() >= 0x1010100f) {

+Net::SSLeay::CTX_set_post_handshake_auth($ctx, 1);
+}
+
# replace arg_hash with created context
$ctx{$host} = $ctx;
 }

The PHA patch was stolen from Joe's explanation of the PHA issue.

With this setup, I can see some TLSv1.3 entries in the 
t/logs/ssl_request_log. For instance when running t/ssl/varlookup.t.


Regards,

Rainer

Re: [VOTE] Release httpd-2.4.37

[Yann Ylavic]

On Thu, Oct 18, 2018 at 4:36 PM Daniel Ruggeri  wrote:
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.37:

+1: It's not just good, it's good enough!

Tested on Debian(s) both with openssl-1.1.0 (system) and openssl-1.1.1
(compiled).

Could not make the test suite framework work with 1.1.1 (cpan -u didn't help).
Although the ssl tests report SUCCESS, httpd actually timeouts on
SSL_peek() (as already reported).
So I also made "real" tests (including h2) with compatible clients
(curl, firefox) and everything worked as expected.

The lights are green for me, thanks everybody for the hard work on
mod_ssl and h2, and of course Daniel for RMing.

Re: [VOTE] Release httpd-2.4.37

[Christophe JAILLET]

Le 18/10/2018 à 16:36, Daniel Ruggeri a écrit :

Hi, all;
   Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.37:

[X] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
sha256: 
aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd 
*httpd-2.4.37.tar.gz



+1

Tested on Ubuntu 18.10. gcc 8.1.0; openssl 1.1.1, event MPM.

CJ

Re: Apache Win crashes with mod_md with no Applink sim

[Gregg Smith]

I objected earlier but am reversing my objection after looking through 
applink.c and the explanation of what it does below. Worse case there's 
a very small bit of unused code in httpd.exe.


Steffen tried one of my binaries and told me off-list the results so it 
seems it is needed, even when httpd & openssl come from the very same vc 
compiler. I use wilcard certs so cannot use mod_md to test the results 
myself.



On 10/19/2018 7:29 AM, William A Rowe Jr wrote:

On Fri, Oct 19, 2018 at 6:15 AM Steffen  wrote:


I changed the subject ( was Re: svn commit: r1748461 - in
/httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c)

William A Rowe Jr wrote: ...mod_php or other weirdness 

What do you mean by weirdness ? Google translate shows it can be a bad
word.



No slight intended; I'm speaking of loading binaries in-process which use
BIO
resource handles from libcrypto (libeay32 or whatever it was called) where
the
binaries arrive from different VC compilers or are built using different
memory
models (/MD vs /MT).

So in the case that a user downloads perl, php, lua, etc built against
different
VC flavors by different open source projects, and loaded in-process
underneath
Apache.exe (httpd) binary, this stub is necessary. In the case that the
user is
loading these different environments and modules built with the same linkage
by the same compiler, this stub is not necessary (except as noted in some
broken flavors of openssl.)

I never talked about a mod-php, as pointed before applink is needed for

phpXapache2_4.dll.  The Microsoft PHP team asked (and still) me to use the
sim, they had some serious reports. Quote PHP team: Yeah, now it turned
out, that the SPKI functionality in PHP requires this shim to be in. The
functionality is available since PHP 5.6 and coupled with Apache could
result an unexpected process exit without the solution mentioned in the
OpenSSL FAQ compiled in.



phpXapache2_4.dll is the apache php module by another name.

"Some reports" may still correspond to the openssl 1.0.2g bug mentioned
in the thread. Or, what is likely going on is that SPKI binaries were
compiled
against OpenSSL using a different version of the compiler.



An other example:
mod_md errors when no applink sim, in the past AL has also reports of the
issue.
Just tested again with AH httpd-2.4.35 with  Openssl 110i, and no
surprise, is does not even start, see below. Replacing the httpd.exe from
AL with the sim  all fine. Looks like a module using ssl needs the sim.



This makes sense if the OpenSSL 1.1.0i is built with a different compiler
and memory model. If it is built with the same, this should be reported to
the openssl project as a bug. The BIO interfaces are used by mod_md,
so this is expected. This is likely the 1.0.2g bug.

In any case, the usage of apache allows for arbitrary modules to be loaded
and in the binaries scenario. It seems the stub should be added in
Apache.exe
whenever mod_ssl/mod_md/aprutil have been linked to libcrypto.

This all goes against your earlier comment to me not to add this patch to
the
Apache.exe binary for building on Windows. You are reversing your objection?

I've seen another objection which suggests that "Apache.exe isn't even
linked to OpenSSL." What's important here is that the stub does not
invoke or link to OpenSSL at all. It simply provides an array of entry
points
to the current Visual Studio C Runtime, which Apache.exe is linked to,
as a shared, exported symbol that can be found by any of the .dll code
loaded in process. >
If so, based especially on mod_md and the possibility of users loading
a flavor of the libcrypto/libssl libraries which weren't created by the same
Visual Studio + memory model as when building Apache, it seems we
should proceed with patching the Apache/httpd top level binary.

Re: [EXTERNAL] SNI extension for healthchecks

[Nebergall, Christopher]

Does this help?

https://bz.apache.org/bugzilla/show_bug.cgi?id=55782

Sent from my iPhone

On Oct 19, 2018, at 3:52 AM, Dominik Stillhard 
mailto:dominik.stillh...@united-security-providers.ch>>
 wrote:

I asked this on the users mailing list and didn’t get any feedback so far, so 
i’ll forward it here. Maybe someone here has an idea…
bugreport: https://bz.apache.org/bugzilla/show_bug.cgi?id=62837


Von: Stillhard, Dominik
Gesendet: Dienstag, 16. Oktober 2018 12:44
An: us...@httpd.apache.org
Betreff: [users@httpd] SNI extension for healthchecks [signed OK]

Hello all

I face the problem, that the sni extension is not set on healthcheck-requests 
to a backend using tls. Because healthchecks are negative, this leads to 
ordinary requests also beeing denied.

on the backend server i have the following error:
AH02033: No hostname was provided via SNI for a name based virtual host
I’ve also investigated it with wireshark, the extionsion is defenitely not set.

My config looks as follows:
-
Listen 127.0.0.1:443
ServerName www.localhost.com


ServerName www.localhost.com
ServerAlias localhost.com
SSLCertificateFile /etc/httpd/ssl/ca.crt
SSLCertificateKeyFile /etc/httpd/ssl/ca.key
SSLEngine on
SSLProxyEngine on

ProxyHCExpr isok {%{REQUEST_STATUS} =~ /^[23]/}
ProxyHCTemplate template hcinterval=5 hcexpr=isok hcmethod=get 
hcuri=/healthcheck.php

  
BalancerMember https://127.0.0.1:8443
BalancerMember https://127.0.0.1:8444
ProxyPreserveHost On
SSLProxyProtocol  TLSv1
  
  
ProxyPass  balancer://mycluster/
ProxyPassReverse  balancer://mycluster/
  

-
I’ve read that ProxyPreserveHost should be «on», but this doesn’t solve the 
problem ..
Am I missing something, or is this eventually a bug in mod_proxy_hcheck?
Thanks in advance for help/ideas on this!

Cheers
Dominik

Re: Apache Win crashes with mod_md with no Applink sim

[William A Rowe Jr]

On Fri, Oct 19, 2018 at 6:15 AM Steffen  wrote:

> I changed the subject ( was Re: svn commit: r1748461 - in
> /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c)
>
> William A Rowe Jr wrote: ...mod_php or other weirdness 
>
> What do you mean by weirdness ? Google translate shows it can be a bad
> word.
>

No slight intended; I'm speaking of loading binaries in-process which use
BIO
resource handles from libcrypto (libeay32 or whatever it was called) where
the
binaries arrive from different VC compilers or are built using different
memory
models (/MD vs /MT).

So in the case that a user downloads perl, php, lua, etc built against
different
VC flavors by different open source projects, and loaded in-process
underneath
Apache.exe (httpd) binary, this stub is necessary. In the case that the
user is
loading these different environments and modules built with the same linkage
by the same compiler, this stub is not necessary (except as noted in some
broken flavors of openssl.)

I never talked about a mod-php, as pointed before applink is needed for
> phpXapache2_4.dll.  The Microsoft PHP team asked (and still) me to use the
> sim, they had some serious reports. Quote PHP team: Yeah, now it turned
> out, that the SPKI functionality in PHP requires this shim to be in. The
> functionality is available since PHP 5.6 and coupled with Apache could
> result an unexpected process exit without the solution mentioned in the
> OpenSSL FAQ compiled in.
>

phpXapache2_4.dll is the apache php module by another name.

"Some reports" may still correspond to the openssl 1.0.2g bug mentioned
in the thread. Or, what is likely going on is that SPKI binaries were
compiled
against OpenSSL using a different version of the compiler.


> An other example:
> mod_md errors when no applink sim, in the past AL has also reports of the
> issue.
> Just tested again with AH httpd-2.4.35 with  Openssl 110i, and no
> surprise, is does not even start, see below. Replacing the httpd.exe from
> AL with the sim  all fine. Looks like a module using ssl needs the sim.
>

This makes sense if the OpenSSL 1.1.0i is built with a different compiler
and memory model. If it is built with the same, this should be reported to
the openssl project as a bug. The BIO interfaces are used by mod_md,
so this is expected. This is likely the 1.0.2g bug.

In any case, the usage of apache allows for arbitrary modules to be loaded
and in the binaries scenario. It seems the stub should be added in
Apache.exe
whenever mod_ssl/mod_md/aprutil have been linked to libcrypto.

This all goes against your earlier comment to me not to add this patch to
the
Apache.exe binary for building on Windows. You are reversing your objection?

I've seen another objection which suggests that "Apache.exe isn't even
linked to OpenSSL." What's important here is that the stub does not
invoke or link to OpenSSL at all. It simply provides an array of entry
points
to the current Visual Studio C Runtime, which Apache.exe is linked to,
as a shared, exported symbol that can be found by any of the .dll code
loaded in process.

If so, based especially on mod_md and the possibility of users loading
a flavor of the libcrypto/libssl libraries which weren't created by the same
Visual Studio + memory model as when building Apache, it seems we
should proceed with patching the Apache/httpd top level binary.

Re: [VOTE] Release httpd-2.4.37

[Stefan Eissing]

+1 

MacOS 10.14, OpenSSL 1.0.2p + 1.1.1, mod-h2 suite, mod-md suite
Ubuntu 18.04 LTS, OpenSSL 1.1.0h, mod-h2 suite

Thanks for RM'ing, Daniel!

> Am 18.10.2018 um 16:36 schrieb Daniel Ruggeri :
> 
> Hi, all;
>   Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.37:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
> sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd 
> *httpd-2.4.37.tar.gz
> 
> -- 
> Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.37

[Ruediger Pluem]

On 10/19/2018 12:10 PM, Apache Lounge wrote:
> 
> No issues seen/reported
> 
> Httpd 36/37 introduced the following build warnings:
> 
> modules\ssl\ssl_engine_init.c(926): warning C4003: not enough arguments for 
> function-like macro invocation 'APLOGNO'
> 
> modules\ssl\ssl_engine_kernel.c(1128): warning C4003: not enough arguments 
> for function-like macro invocation 'APLOGNO'
> modules\ssl\ssl_engine_kernel.c(1147): warning C4003: not enough arguments 
> for function-like macro invocation 'APLOGNO'

Hm. Looks like it was missed to fill in the error numbers during backport.

Regards

Rüdiger

Re: [VOTE] Release httpd-2.4.37

[Jim Jagielski]

+1:

  o macOS 10.13.6, Xcode 10, OpenSSL 1.1.1 and 1.0.2p
  o CentOS 5&6, OpenSSL 1.0.2, 64bit

Thx for RMing!

> On Oct 18, 2018, at 10:36 AM, Daniel Ruggeri  wrote:
> 
> Hi, all;
>   Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.37:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
> sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd 
> *httpd-2.4.37.tar.gz
> 
> -- 
> Daniel Ruggeri

Apache Win crashes with mod_md with no Applink sim

[Steffen]

I changed the subject ( was Re: svn commit: r1748461 - in 
/httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c)


William A Rowe Jr wrote: ...mod_php or other weirdness 

What do you mean by weirdness ? Google translate shows it can be a bad word.

I never talked about a mod-php, as pointed before applink is needed for 
phpXapache2_4.dll.  The Microsoft PHP team asked (and still) me to use 
the sim, they had some serious reports. Quote PHP team: Yeah, now it 
turned out, that the SPKI functionality in PHP requires this shim to be 
in. The functionality is available since PHP 5.6 and coupled with Apache 
could result an unexpected process exit without the solution mentioned 
in the OpenSSL FAQ compiled in.


I mentioned already back in 2016, so I cannot stipulate enough to you 
that applink sim is needed. Of course no reports on AL, because applink 
is in for years.


An other example:
mod_md errors when no applink sim, in the past AL has also reports of 
the issue.
Just tested again with AH httpd-2.4.35 with  Openssl 110i, and no 
surprise, is does not even start, see below. Replacing the httpd.exe 
from AL with the sim  all fine. Looks like a module using ssl needs the sim.


And for abs.exe, leave it in, does not harm and we are on the save side.

Regards,

Steffen

run with AH: httpd-2.4.35-o110i-x64-vc14.zip, Apache does not start

[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] 
mod_md.c(1012): AH10070: initializing post config dry run
[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] 
mod_md.c(357): AH10037: server seems not reachable via http: (port 
80->80) and reachable via https: (port 443->443)
[Mon Oct 15 15:05:01.883939 2018] [md:warn] [pid 6796:tid 464] AH10045: 
No VirtualHost matches Managed Domain vosadministraties.nl
[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] 
mod_md.c(389): AH10039: Completed MD[vosadministraties.nl, 
CA=https://acme-v01.api.letsencrypt.org/directory, Proto=ACME, 
Agreement=(null), Drive=1, renew=2134720512]
[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] 
md_reg.c(706): sync: found 1 mds in store
[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464] 
md_reg.c(793): apachelounge.nl: update renew norm=2109194240, 
window=2134720512

OPENSSL_Uplink(7FFB73F334C8,08): no OPENSSL_Applink

On 17-10-18 18:17, William A Rowe Jr wrote:
On Fri, Oct 12, 2018 at 4:54 PM William A Rowe Jr > wrote:


Great, I'll proceed with changing ab.c to remove the hack, since
it is unneeded when ab.c is compiled by the same toolchain as
libcrypto.dll, isn't available in non-openssl distributions, and
was deprecated in 1.1.1 again.


Note, I'll only proceed to remove the hack from trunk. I see no reason 
to make any cosmetic or build changes to 2.4.x branch. Any fallout to 
the trunk change will be uncovered in alpha/beta review. If we are 
unwilling to support the feature in httpd.exe we should not do so for 
ab.c either. (IIRC there was some subtle lingering BIO usage from 
mod_ssl for the initialization phase.)


Anyone who wants to enable the applink stub logic for mod_php or other 
weirdness is welcome to patch that either by 1) adding the applink.c 
to abs.exe and/or httpd.exe linkage, or the main() source file can 
#include that "".


Anyone interested can proceed to patch both and provision
applink.c when working with OpenSSL 1.1.1, so I don't need to
raise a ticket at that project.


Regression #7396  was 
fixed with 92ebf6c 
 for 
OpenSSL 1.1.1a. The oversight of dropping applink.c appears to have 
been unintended.


Thanks to you all for your review and re-evaluation of the past and 
current situations with OpenSSL.

Re: [VOTE] Release httpd-2.4.37

[Apache Lounge]

No issues seen/reported

Httpd 36/37 introduced the following build warnings:

modules\ssl\ssl_engine_init.c(926): warning C4003: not enough 
arguments for function-like macro invocation 'APLOGNO'


modules\ssl\ssl_engine_kernel.c(1128): warning C4003: not enough 
arguments for function-like macro invocation 'APLOGNO'
modules\ssl\ssl_engine_kernel.c(1147): warning C4003: not enough 
arguments for function-like macro invocation 'APLOGNO'


For you info warnings mod_ssl:


All warnings Win32:

..win32\httpd-2.4\modules\ssl\ssl_engine_init.c(926): warning C4003: 
not enough arguments for function-like macro invocation 'APLOGNO'
..win32\httpd-2.4\modules\ssl\ssl_engine_kernel.c(1128): warning 
C4003: not enough arguments for function-like macro invocation 
'APLOGNO'
..win32\httpd-2.4\modules\ssl\ssl_engine_kernel.c(1147): warning 
C4003: not enough arguments for function-like macro invocation 
'APLOGNO'
..win32\httpd-2.4\modules\ssl\ssl_engine_kernel.c(2605): warning 
C4018: '<': signed/unsigned mismatch


All warnings Win64

..win64\httpd-2.4\modules\ssl\ssl_engine_config.c(551): warning C4267: 
'initializing': conversion from 'size_t' to 'int', possible loss of 
data
..win64\httpd-2.4\modules\ssl\ssl_engine_config.c(639): warning C4267: 
'initializing': conversion from 'size_t' to 'int', possible loss of 
data
..win64\httpd-2.4\modules\ssl\ssl_engine_init.c(258): warning C4267: 
'=': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_init.c(926): warning C4003: 
not enough arguments for function-like macro invocation 'APLOGNO'
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(624): warning C4267: 
'function': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(630): warning C4267: 
'+=': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(673): warning C4267: 
'function': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(807): warning C4267: 
'function': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(829): warning C4267: 
'=': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(859): warning C4267: 
'function': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(1216): warning C4244: 
'function': conversion from '__int64' to 'unsigned int', possible loss 
of data
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(1542): warning C4018: 
'<': signed/unsigned mismatch
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(1560): warning C4267: 
'-=': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(1904): warning C4018: 
'>': signed/unsigned mismatch
..win64\httpd-2.4\modules\ssl\ssl_engine_kernel.c(1128): warning 
C4003: not enough arguments for function-like macro invocation 
'APLOGNO'
..win64\httpd-2.4\modules\ssl\ssl_engine_kernel.c(1147): warning 
C4003: not enough arguments for function-like macro invocation 
'APLOGNO'
..win64\httpd-2.4\modules\ssl\ssl_engine_kernel.c(2605): warning 
C4018: '<': signed/unsigned mismatch
..win64\httpd-2.4\modules\ssl\ssl_engine_log.c(128): warning C4267: 
'=': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_pphrase.c(478): warning 
C4267: '=': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_pphrase.c(570): warning 
C4267: '=': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_pphrase.c(609): warning 
C4267: '=': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_rand.c(154): warning C4267: 
'function': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_rand.c(162): warning C4267: 
'return': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_engine_vars.c(668): warning C4267: 
'=': conversion from 'size_t' to 'int', possible loss of data
..win64\httpd-2.4\modules\ssl\ssl_util_ssl.c(141): warning C4267: '=': 
conversion from 'size_t' to 'int', possible loss of data





On Thursday 18/10/2018 at 16:36, Daniel Ruggeri  wrote:

Hi, all;
   Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.37:

[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
sha256: 
aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd 
*httpd-2.4.37.tar.gz


--
Daniel 

Re: [VOTE] Release httpd-2.4.37

[Joe Orton]

On Thu, Oct 18, 2018 at 09:36:41AM -0500, Daniel Ruggeri wrote:
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate
> tarball as 2.4.37:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.

+1 for release from me, thanks again for RMing again ;)

Regards, Joe

Re: svn commit: r1844309 - /httpd/test/framework/trunk/t/htdocs/modules/cgi/ocsp.pl.PL

[Joe Orton]

On Fri, Oct 19, 2018 at 11:39:27AM +0200, Rainer Jung wrote:
> Concerning your simpler approach: it is OK if we give up supporting 0.9.8
> but we should probably keep the "or `$openssl list -commands 2>&1` !~
> /ocsp/" part of the test.

OK good point, let's leave it as-is.  r1844320 works for me, thanks!

Re: svn commit: r1844309 - /httpd/test/framework/trunk/t/htdocs/modules/cgi/ocsp.pl.PL

[Rainer Jung]

Am 19.10.2018 um 11:01 schrieb Joe Orton:

On Fri, Oct 19, 2018 at 07:25:55AM -, rj...@apache.org wrote:

Author: rjung
Date: Fri Oct 19 07:25:55 2018
New Revision: 1844309

URL: http://svn.apache.org/viewvc?rev=1844309=rev
Log:
Do not use STDIN / STDOUT as -reqin and -respout
for "openssl ocsp", since that is supported only
in OpenSSL 1.0.2 and above.

Instead use temporary files.


This doesn't work at all for me with Perl 5.26.2 / File::Temp 0.230.600

tempnam() from File::Temp is not exported and takes two arguments, are
you testing with a different version?


Sorry, tempnam => tmpnam. Committed in r1844320. It at least works here. 
Would you be able to recheck?



Compatibility functions:

  $unopened_file = File::Temp::tempnam( $dir, $pfx );

I would be happy to restrict this test to running with recent versions
of OpenSSL if it requires excessive hacks to make working with older
ones.

A simpler/safer test for the OpenSSL versions would be

Index: t/ssl/ocsp.t
===
--- t/ssl/ocsp.t(revision 1844314)
+++ t/ssl/ocsp.t(working copy)
@@ -20,9 +20,12 @@
  # Requires OpenSSL 1.1, can't find a simple way to test for OCSP
  # support in earlier versions without messing around with stderr
  my $openssl = Apache::TestSSLCA::openssl();
+my $version = Apache::TestSSLCA::version();
+my $min_version = "1.0.2";
+
  if (!have_min_apache_version('2.4.26')
-or `$openssl list -commands 2>&1` !~ /ocsp/) {
-print "1..0 # skip: No OpenSSL or mod_ssl OCSP support";
+or Apache::Test::normalize_vstring($version) < 
Apache::Test::normalize_vstring($min_version)) {
+print "1..0 # skip: Requires OpenSSL $min_version (got $version) and mod_ssl 
OCSP support";
  exit 0;
  }


The problem here is, that what broke the test originally was not the 
wrong OpenSSL version but instead relying on a feature of it (allowing 
-reqin and -respout to point to STDIN resp. STDOUT). That's why I would 
prefer fixing the test. At least here in my environment it now works 
also with OpenSSL 0.9.8.


Not sure, if the change I applied (using temporary files for input and 
output) should already be rated as "excessive hacks". I agree, it makes 
a simple script roughly twice the size, but some of the new lines are 
because of checking the result of the system() call (we had a fire and 
forget exec() before).


Concerning your simpler approach: it is OK if we give up supporting 
0.9.8 but we should probably keep the "or `$openssl list -commands 2>&1` 
!~ /ocsp/" part of the test.


Regards,

Rainer

Re: svn commit: r1844309 - /httpd/test/framework/trunk/t/htdocs/modules/cgi/ocsp.pl.PL

[Ruediger Pluem]

On 10/19/2018 11:01 AM, Joe Orton wrote:
> On Fri, Oct 19, 2018 at 07:25:55AM -, rj...@apache.org wrote:
>> Author: rjung
>> Date: Fri Oct 19 07:25:55 2018
>> New Revision: 1844309
>>
>> URL: http://svn.apache.org/viewvc?rev=1844309=rev
>> Log:
>> Do not use STDIN / STDOUT as -reqin and -respout
>> for "openssl ocsp", since that is supported only
>> in OpenSSL 1.0.2 and above.
>>
>> Instead use temporary files.
> 
> This doesn't work at all for me with Perl 5.26.2 / File::Temp 0.230.600
> 
> tempnam() from File::Temp is not exported and takes two arguments, are 
> you testing with a different version?
> 
>Compatibility functions:
> 
>  $unopened_file = File::Temp::tempnam( $dir, $pfx );
> 
> I would be happy to restrict this test to running with recent versions 
> of OpenSSL if it requires excessive hacks to make working with older 
> ones.
> 
> A simpler/safer test for the OpenSSL versions would be
> 
> Index: t/ssl/ocsp.t
> ===
> --- t/ssl/ocsp.t  (revision 1844314)
> +++ t/ssl/ocsp.t  (working copy)
> @@ -20,9 +20,12 @@
>  # Requires OpenSSL 1.1, can't find a simple way to test for OCSP
>  # support in earlier versions without messing around with stderr
>  my $openssl = Apache::TestSSLCA::openssl();
> +my $version = Apache::TestSSLCA::version();
> +my $min_version = "1.0.2";
> +
>  if (!have_min_apache_version('2.4.26')
> -or `$openssl list -commands 2>&1` !~ /ocsp/) {
> -print "1..0 # skip: No OpenSSL or mod_ssl OCSP support";
> +or Apache::Test::normalize_vstring($version) < 
> Apache::Test::normalize_vstring($min_version)) {
> +print "1..0 # skip: Requires OpenSSL $min_version (got $version) and 
> mod_ssl OCSP support";

How would we know in this case that this recent Openssl version was build with 
ocsp support?

Regards

Rüdiger

Re: svn commit: r1844309 - /httpd/test/framework/trunk/t/htdocs/modules/cgi/ocsp.pl.PL

[Joe Orton]

On Fri, Oct 19, 2018 at 07:25:55AM -, rj...@apache.org wrote:
> Author: rjung
> Date: Fri Oct 19 07:25:55 2018
> New Revision: 1844309
> 
> URL: http://svn.apache.org/viewvc?rev=1844309=rev
> Log:
> Do not use STDIN / STDOUT as -reqin and -respout
> for "openssl ocsp", since that is supported only
> in OpenSSL 1.0.2 and above.
> 
> Instead use temporary files.

This doesn't work at all for me with Perl 5.26.2 / File::Temp 0.230.600

tempnam() from File::Temp is not exported and takes two arguments, are 
you testing with a different version?

   Compatibility functions:

 $unopened_file = File::Temp::tempnam( $dir, $pfx );

I would be happy to restrict this test to running with recent versions 
of OpenSSL if it requires excessive hacks to make working with older 
ones.

A simpler/safer test for the OpenSSL versions would be

Index: t/ssl/ocsp.t
===
--- t/ssl/ocsp.t(revision 1844314)
+++ t/ssl/ocsp.t(working copy)
@@ -20,9 +20,12 @@
 # Requires OpenSSL 1.1, can't find a simple way to test for OCSP
 # support in earlier versions without messing around with stderr
 my $openssl = Apache::TestSSLCA::openssl();
+my $version = Apache::TestSSLCA::version();
+my $min_version = "1.0.2";
+
 if (!have_min_apache_version('2.4.26')
-or `$openssl list -commands 2>&1` !~ /ocsp/) {
-print "1..0 # skip: No OpenSSL or mod_ssl OCSP support";
+or Apache::Test::normalize_vstring($version) < 
Apache::Test::normalize_vstring($min_version)) {
+print "1..0 # skip: Requires OpenSSL $min_version (got $version) and 
mod_ssl OCSP support";
 exit 0;
 }
 

SNI extension for healthchecks

[Dominik Stillhard]

I asked this on the users mailing list and didn’t get any feedback so far, so 
i’ll forward it here. Maybe someone here has an idea…
bugreport: https://bz.apache.org/bugzilla/show_bug.cgi?id=62837


Von: Stillhard, Dominik
Gesendet: Dienstag, 16. Oktober 2018 12:44
An: us...@httpd.apache.org
Betreff: [users@httpd] SNI extension for healthchecks [signed OK]

Hello all

I face the problem, that the sni extension is not set on healthcheck-requests 
to a backend using tls. Because healthchecks are negative, this leads to 
ordinary requests also beeing denied.

on the backend server i have the following error:
AH02033: No hostname was provided via SNI for a name based virtual host
I’ve also investigated it with wireshark, the extionsion is defenitely not set.

My config looks as follows:
-
Listen 127.0.0.1:443
ServerName www.localhost.com


ServerName www.localhost.com
ServerAlias localhost.com
SSLCertificateFile /etc/httpd/ssl/ca.crt
SSLCertificateKeyFile /etc/httpd/ssl/ca.key
SSLEngine on
SSLProxyEngine on

ProxyHCExpr isok {%{REQUEST_STATUS} =~ /^[23]/}
ProxyHCTemplate template hcinterval=5 hcexpr=isok hcmethod=get 
hcuri=/healthcheck.php

  
BalancerMember https://127.0.0.1:8443
BalancerMember https://127.0.0.1:8444
ProxyPreserveHost On
SSLProxyProtocol  TLSv1
  
  
ProxyPass  balancer://mycluster/
ProxyPassReverse  balancer://mycluster/
  

-
I’ve read that ProxyPreserveHost should be «on», but this doesn’t solve the 
problem ..
Am I missing something, or is this eventually a bug in mod_proxy_hcheck?
Thanks in advance for help/ideas on this!

Cheers
Dominik



smime.p7s
Description: S/MIME cryptographic signature