You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Steffen <in...@apachelounge.com> on 2018/10/19 11:15:00 UTC
Apache Win crashes with mod_md with no Applink sim
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(00007FFB73F334C8,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 <wrowe@rowe-clan.net
> <ma...@rowe-clan.net>> 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 "<include/openssl/applink.c>".
>
> 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 <https://github.com/openssl/openssl/issues/7396> was
> fixed with 92ebf6c
> <https://github.com/openssl/openssl/commit/92ebf6c4c21ff4b41ba1fd69af74b2039e138114> 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: Apache Win crashes with mod_md with no Applink sim
Posted by Gregg Smith <gl...@gknw.net>.
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 <in...@apachelounge.com> 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: Apache Win crashes with mod_md with no Applink sim
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Oct 19, 2018 at 6:15 AM Steffen <in...@apachelounge.com> 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.