Re: Experimental C unit test suite available for hacking

[Micha Lenk]

On 05/23/2018 10:21 PM, Christophe Jaillet wrote:
I can reproduce the issue if I don't pass any --enable-mpms-shared 
paramater to ./configure.

Having --with-mpm=xx only also triggers the building issue.

What is your ./configure command line?


The initial ./configure command line was:

./configure --prefix=/home/build/target --with-apr=/home/build/target 
--with-apr-util=/home/build/target --enable-modules=most


Can you try to add --enable-mpms-shared=event (or =all) and re-configure 
and build?


I tried several combinations of --with-mpm=worker and 
--with-mpms-shared=all, but none of them worked (all attempts with "make 
clean"). The most recent attempt used the following ./configure command 
line:


./configure --prefix=/home/mlenk/Upstream/Apache/target 
--with-apr=/home/mlenk/Upstream/Apache/target 
--with-apr-util=/home/mlenk/Upstream/Apache/target --with-mpm=worker 
--with-mpms-shared=all --enable-mods-static=most --enable-load-all-modules


Regards,
Micha

Re: Experimental C unit test suite available for hacking

[Micha Lenk]

Hi Yann,

On 05/24/2018 10:41 AM, Yann Ylavic wrote:

./configure --prefix=/home/mlenk/Upstream/Apache/target
--with-apr=/home/mlenk/Upstream/Apache/target
--with-apr-util=/home/mlenk/Upstream/Apache/target --with-mpm=worker
--with-mpms-shared=all --enable-mods-static=most --enable-load-all-modules


This should be --enable-mpms-shared=all (not --with-...).


Drat. What a good catch! I should have enjoyed a coffee before trying 
the suggested work around.



Btw, as Jacob noted, the attached patch seems to work for me (even
without the above option).


Yes, for me too, except that the linker problem with undefined symbols 
now seems to shift to the modules. I had to disable a few modules 
(--enable-mods-static=most --disable-apreq --disable-proxy-fcgi 
--disable-session-cookie --disable-session-dbd --disable-dav) to finally 
get to a successful build.


Thanks for your help.

Regards,
Micha

Re: Experimental C unit test suite available for hacking

[Yann Ylavic]

On Thu, May 24, 2018 at 11:28 AM, Yann Ylavic  wrote:
> On Thu, May 24, 2018 at 11:23 AM, Yann Ylavic  wrote:
>> On Thu, May 24, 2018 at 11:06 AM, Micha Lenk  wrote:
>>>
>>> On 05/24/2018 10:41 AM, Yann Ylavic wrote:
>>>
 Btw, as Jacob noted, the attached patch seems to work for me (even
 without the above option).
>>>
>>> Yes, for me too, except that the linker problem with undefined symbols now
>>> seems to shift to the modules. I had to disable a few modules
>>> (--enable-mods-static=most --disable-apreq --disable-proxy-fcgi
>>> --disable-session-cookie --disable-session-dbd --disable-dav) to finally get
>>> to a successful build.
>>
>> Oh indeed, the correct order seems to be:
>>
>> PROGRAM_DEPENDENCIES = \
>>   $(MPM_LIB) \
>>   $(BUILTIN_LIBS) \
>>   server/libmain.la \
>>   os/$(OS_DIR)/libos.la
>
> Argh no, it now fails with --enable-mods-shared=...

Looks like the right order to me, however it fails with shared modules
because "server/core.c" (in libmain) uses ap_set_etag() function from
"modules/http/http_etag.c" (in BUILTIN_LIBS's libmod_http).

I think "core" shouldn't depend on a module (even builtin), for
instance ap_set_{last_modified,accept_range,content_length,...} also
used by the core are defined in "server/protocol.c".

WDYT?

Re: Experimental C unit test suite available for hacking

[Yann Ylavic]

Hi Micha,

On Thu, May 24, 2018 at 10:29 AM, Micha Lenk  wrote:
>
> I tried several combinations of --with-mpm=worker and
> --with-mpms-shared=all, but none of them worked (all attempts with "make
> clean"). The most recent attempt used the following ./configure command
> line:
>
> ./configure --prefix=/home/mlenk/Upstream/Apache/target
> --with-apr=/home/mlenk/Upstream/Apache/target
> --with-apr-util=/home/mlenk/Upstream/Apache/target --with-mpm=worker
> --with-mpms-shared=all --enable-mods-static=most --enable-load-all-modules

This should be --enable-mpms-shared=all (not --with-...).

Btw, as Jacob noted, the attached patch seems to work for me (even
without the above option).

Regards,
Yann.
Index: Makefile.in
===
--- Makefile.in	(revision 1832123)
+++ Makefile.in	(working copy)
@@ -7,9 +7,9 @@ PROGRAM_SOURCES  = modules.c
 PROGRAM_LDADD= buildmark.o $(HTTPD_LDFLAGS) $(PROGRAM_DEPENDENCIES) $(HTTPD_LIBS) $(EXTRA_LIBS) $(AP_LIBS) $(LIBS)
 PROGRAM_PRELINK  = $(COMPILE) -c $(top_srcdir)/server/buildmark.c
 PROGRAM_DEPENDENCIES = \
+  $(MPM_LIB) \
   server/libmain.la \
   $(BUILTIN_LIBS) \
-  $(MPM_LIB) \
   os/$(OS_DIR)/libos.la
 
 sbin_PROGRAMS   = $(PROGRAM_NAME)

Re: Experimental C unit test suite available for hacking

[Yann Ylavic]

On Thu, May 24, 2018 at 11:06 AM, Micha Lenk  wrote:
>
> On 05/24/2018 10:41 AM, Yann Ylavic wrote:
>
>> Btw, as Jacob noted, the attached patch seems to work for me (even
>> without the above option).
>
> Yes, for me too, except that the linker problem with undefined symbols now
> seems to shift to the modules. I had to disable a few modules
> (--enable-mods-static=most --disable-apreq --disable-proxy-fcgi
> --disable-session-cookie --disable-session-dbd --disable-dav) to finally get
> to a successful build.

Oh indeed, the correct order seems to be:

PROGRAM_DEPENDENCIES = \
  $(MPM_LIB) \
  $(BUILTIN_LIBS) \
  server/libmain.la \
  os/$(OS_DIR)/libos.la


Regards,
Yann.

Re: Experimental C unit test suite available for hacking

[Yann Ylavic]

On Thu, May 24, 2018 at 11:23 AM, Yann Ylavic  wrote:
> On Thu, May 24, 2018 at 11:06 AM, Micha Lenk  wrote:
>>
>> On 05/24/2018 10:41 AM, Yann Ylavic wrote:
>>
>>> Btw, as Jacob noted, the attached patch seems to work for me (even
>>> without the above option).
>>
>> Yes, for me too, except that the linker problem with undefined symbols now
>> seems to shift to the modules. I had to disable a few modules
>> (--enable-mods-static=most --disable-apreq --disable-proxy-fcgi
>> --disable-session-cookie --disable-session-dbd --disable-dav) to finally get
>> to a successful build.
>
> Oh indeed, the correct order seems to be:
>
> PROGRAM_DEPENDENCIES = \
>   $(MPM_LIB) \
>   $(BUILTIN_LIBS) \
>   server/libmain.la \
>   os/$(OS_DIR)/libos.la

Argh no, it now fails with --enable-mods-shared=...

Re: Experimental C unit test suite available for hacking

[Micha Lenk]

Hi Yann,

On 05/24/2018 11:23 AM, Yann Ylavic wrote:

Yes, for me too, except that the linker problem with undefined symbols now
seems to shift to the modules. I had to disable a few modules
(--enable-mods-static=most --disable-apreq --disable-proxy-fcgi
--disable-session-cookie --disable-session-dbd --disable-dav) to finally get
to a successful build.


Oh indeed, the correct order seems to be:


I'd rather expect some fixes in the affected modules linker order.

Regards,
Micha

Re: Experimental C unit test suite available for hacking

[Micha Lenk]

Hi Yann,

On 05/24/2018 10:41 AM, Yann Ylavic wrote:

--- Makefile.in (revision 1832123)
+++ Makefile.in (working copy)
@@ -7,9 +7,9 @@ PROGRAM_SOURCES  = modules.c
  PROGRAM_LDADD= buildmark.o $(HTTPD_LDFLAGS) $(PROGRAM_DEPENDENCIES) 
$(HTTPD_LIBS) $(EXTRA_LIBS) $(AP_LIBS) $(LIBS)
  PROGRAM_PRELINK  = $(COMPILE) -c $(top_srcdir)/server/buildmark.c
  PROGRAM_DEPENDENCIES = \
+  $(MPM_LIB) \
server/libmain.la \
$(BUILTIN_LIBS) \
-  $(MPM_LIB) \
os/$(OS_DIR)/libos.la
  
  sbin_PROGRAMS   = $(PROGRAM_NAME)


I've just tested several different library orders, but none of them work 
for me (even without the problematic modules I mentioned in the other 
mail). The library order as you are suggesting above is the only one 
that works for me.


I'll look into the modules issue later.

Regards,
Micha

https vhosts

[Stefan Eissing]

Do we have a configuration option to allow https://hostname/ only to matching 
vhosts without any default fallback?

Scenario: 
- a site with vhost A and B
- vhost B is taken out, DNS still points there (for a while)
- browsers opening https://B/ will get the certificate of A and complain

I do not want to present a "wrong" certificate, I want the SSL connection to 
fail. Does that make sense?

Thanks for the help,

Stefan

Re: Experimental C unit test suite available for hacking

[Micha Lenk]

Hi Yann,

FWIW I've found a very good explanation of what's going on during 
linking and why the library order in static linking is so important.

https://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking

On 05/24/2018 12:00 PM, Yann Ylavic wrote:

Looks like the right order to me, however it fails with shared modules
because "server/core.c" (in libmain) uses ap_set_etag() function from
"modules/http/http_etag.c" (in BUILTIN_LIBS's libmod_http).


This could indicate that the default_handler() function which calls 
ap_set_etag() should better be moved to some file in modules/http/. Of 
course that opens a totally different can of worms...



I think "core" shouldn't depend on a module (even builtin), for
instance ap_set_{last_modified,accept_range,content_length,...} also
used by the core are defined in "server/protocol.c".

WDYT?


Well, first things first. Let's first fix trunk to be buildable again on 
build systems that really only link the needed symbols and thus rely on 
the correct library order during linking.


Regards,
Micha

Re: Experimental C unit test suite available for hacking

[Yann Ylavic]

On Thu, May 24, 2018 at 12:11 PM, Micha Lenk  wrote:
>
> On 05/24/2018 12:00 PM, Yann Ylavic wrote:
>
>> I think "core" shouldn't depend on a module (even builtin), for
>> instance ap_set_{last_modified,accept_range,content_length,...} also
>> used by the core are defined in "server/protocol.c".
>>
>> WDYT?
>
> Well, first things first. Let's first fix trunk to be buildable again on
> build systems that really only link the needed symbols and thus rely on the
> correct library order during linking.

I think this is *the* dependency issue, the order in
PROGRAM_DEPENDENCIES should make modules depend on core and not the
other way around.

With this patch, both static and shared builds work for me:

Index: Makefile.in
===
--- Makefile.in(revision 1832123)
+++ Makefile.in(working copy)
@@ -7,9 +7,9 @@ PROGRAM_SOURCES  = modules.c
 PROGRAM_LDADD= buildmark.o $(HTTPD_LDFLAGS)
$(PROGRAM_DEPENDENCIES) $(HTTPD_LIBS) $(EXTRA_LIBS) $(AP_LIBS) $(LIBS)
 PROGRAM_PRELINK  = $(COMPILE) -c $(top_srcdir)/server/buildmark.c
 PROGRAM_DEPENDENCIES = \
+  $(MPM_LIB) \
+  $(BUILTIN_LIBS) \
   server/libmain.la \
-  $(BUILTIN_LIBS) \
-  $(MPM_LIB) \
   os/$(OS_DIR)/libos.la

 sbin_PROGRAMS   = $(PROGRAM_NAME)
Index: modules/http/http_etag.c
===
--- modules/http/http_etag.c(revision 1832123)
+++ modules/http/http_etag.c(working copy)
@@ -14,6 +14,7 @@
  * limitations under the License.
  */

+#ifdef INCLUDE_FROM_CORE
 #include "apr_strings.h"
 #include "apr_thread_proc.h"/* for RLIMIT stuff */

@@ -218,3 +219,4 @@ AP_DECLARE(void) ap_set_etag(request_rec *r)

 apr_table_setn(r->headers_out, "ETag", etag);
 }
+#endif
Index: server/protocol.c
===
--- server/protocol.c(revision 1832123)
+++ server/protocol.c(working copy)
@@ -164,6 +164,9 @@ AP_DECLARE(void) ap_set_content_length(request_rec
apr_off_t_toa(r->pool, clength));
 }

+#define INCLUDE_FROM_CORE
+#include "../modules/http/http_etag.c"
+
 /*
  * Return the latest rational time from a request/mtime (modification time)
  * pair.  We return the mtime unless it's in the future, in which case we
_

Of course it should be a real move of the code...

Re: Experimental C unit test suite available for hacking

[Micha Lenk]

Hi Yann,

On 05/24/2018 12:31 PM, Yann Ylavic wrote:

Well, first things first. Let's first fix trunk to be buildable again on
build systems that really only link the needed symbols and thus rely on the
correct library order during linking.


I think this is*the*  dependency issue, the order in
PROGRAM_DEPENDENCIES should make modules depend on core and not the
other way around.


Yes, sounds reasonable. With the little knowledge about the build system 
I was just blindly moving library orders around without looking into the 
semantical meaning of these dependencies.



With this patch, both static and shared builds work for me:


Confirmed. Works for me too.

The only thing that I am a bit concerned about is, why is the HTTP ETag 
functionality now part of the core, and not part of the http module 
anymore? Isn't this somewhat adverse to other efforts to move more code 
from core to modules?


Regards,
Micha

Re: https vhosts

[Yann Ylavic]

On Thu, May 24, 2018 at 1:57 PM, Stefan Eissing
 wrote:
>
>> Am 24.05.2018 um 13:51 schrieb Yann Ylavic :
>>
>> That'd work (and looks better than Stefan's SNI oriented proposal),
>> but I wish we had something working for non-SSL vhosts too,
>> UseDefaultVHost OFF|ON?
>
> Could work also, if this means that SSL connections with SNI are then
> aborted right away.

Yes, I think that mod_ssl could handle the OFF case earlier, depending
on SNI vs vhost's ServerName/Alias.

> As explained, I do want such hosts to simply not
> work with https:, and avoid a "not secure" warning first.

Yes SSL is special, the "plain" case is worth it too IMHO (checked
elsewhere, but still based on the same directive).

Re: https vhosts

[Eric Covener]

On Thu, May 24, 2018 at 7:51 AM, Yann Ylavic  wrote:
> On Thu, May 24, 2018 at 1:44 PM, Eric Covener  wrote:
>> On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing
>>  wrote:
>>>
>>>
 Am 24.05.2018 um 13:28 schrieb Eric Covener :

 On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing
  wrote:
> Do we have a configuration option to allow https://hostname/ only to 
> matching vhosts without any default fallback?
>
> Scenario:
> - a site with vhost A and B
> - vhost B is taken out, DNS still points there (for a while)
> - browsers opening https://B/ will get the certificate of A and complain
>
> I do not want to present a "wrong" certificate, I want the SSL connection 
> to fail. Does that make sense?

 I don't think it exists for SSL or non-SSL today -- you have to
 capture them in the first-listed VH for a address/port combo.
>>>
>>> Which, in case of SSL, needs to present a certificate that does not match 
>>> and browsers issue their "not trustworthy" warnings. Where, in reality (ha, 
>>> reality on the internet!) the site does not exist and it is impossible to 
>>> make a secure connection to it.
>>>
>>> So, we are lacking an option here to abort SSL connections without a vhost 
>>> match, it seems. Something like
>>>
>>> SSLStrictSNIVHostCheck require-match
>>
>> a more user oriented option:
>>
>> SSLUseDefaultCertificate OFF|ON
>> Default: ON
>> When the server cannot find a matching virtual host for an SSL
>> request, it will uses the certificate configured in the default
>> virtual host for an address:port combination. Setting this directive
>> to OFF will instead { abort the connection, send an alert, halt and
>> catch fire}.
>
> That'd work (and looks better than Stefan's SNI oriented proposal),
> but I wish we had something working for non-SSL vhosts too,
> UseDefaultVHost OFF|ON?

Thinking about base server and how scanners report it the "vulnerability"...

AllowUnmatchedHost[name]?
RejectUnknownHost[name]?

I agree re: generalizing it. I think if someone wanted one w/o the
other they can just specify a ServerAlias anyway.

Re: https vhosts

[Yann Ylavic]

On Thu, May 24, 2018 at 2:08 PM, Stefan Eissing
 wrote:
>
>
>> Am 24.05.2018 um 14:07 schrieb Yann Ylavic :
>>
>> On Thu, May 24, 2018 at 1:57 PM, Stefan Eissing
>>  wrote:
>>>
 Am 24.05.2018 um 13:51 schrieb Yann Ylavic :

 That'd work (and looks better than Stefan's SNI oriented proposal),
 but I wish we had something working for non-SSL vhosts too,
 UseDefaultVHost OFF|ON?
>>>
>>> Could work also, if this means that SSL connections with SNI are then
>>> aborted right away.
>>
>> Yes, I think that mod_ssl could handle the OFF case earlier, depending
>> on SNI vs vhost's ServerName/Alias.
>>
>>> As explained, I do want such hosts to simply not
>>> work with https:, and avoid a "not secure" warning first.
>>
>> Yes SSL is special, the "plain" case is worth it too IMHO (checked
>> elsewhere, but still based on the same directive).
>
> Agreed.

The "plain" case would probably also catch mismatching SSL vhosts with
non-SNI clients.

Re: https vhosts

[Stefan Eissing]

> Am 24.05.2018 um 14:07 schrieb Yann Ylavic :
> 
> On Thu, May 24, 2018 at 1:57 PM, Stefan Eissing
>  wrote:
>> 
>>> Am 24.05.2018 um 13:51 schrieb Yann Ylavic :
>>> 
>>> That'd work (and looks better than Stefan's SNI oriented proposal),
>>> but I wish we had something working for non-SSL vhosts too,
>>> UseDefaultVHost OFF|ON?
>> 
>> Could work also, if this means that SSL connections with SNI are then
>> aborted right away.
> 
> Yes, I think that mod_ssl could handle the OFF case earlier, depending
> on SNI vs vhost's ServerName/Alias.
> 
>> As explained, I do want such hosts to simply not
>> work with https:, and avoid a "not secure" warning first.
> 
> Yes SSL is special, the "plain" case is worth it too IMHO (checked
> elsewhere, but still based on the same directive).

Agreed.

Re: Experimental C unit test suite available for hacking

[William A Rowe Jr]

On Thu, May 24, 2018, 06:34 Eric Covener  wrote:

> On Thu, May 24, 2018 at 7:23 AM, Micha Lenk  wrote:
> > Hi Yann,
> >
> > On 05/24/2018 12:31 PM, Yann Ylavic wrote:
> >>>
> >>> Well, first things first. Let's first fix trunk to be buildable again
> on
> >>> build systems that really only link the needed symbols and thus rely on
> >>> the
> >>> correct library order during linking.
> >>
> >>
> >> I think this is*the*  dependency issue, the order in
> >> PROGRAM_DEPENDENCIES should make modules depend on core and not the
> >> other way around.
> >
> >
> > Yes, sounds reasonable. With the little knowledge about the build system
> I
> > was just blindly moving library orders around without looking into the
> > semantical meaning of these dependencies.
> >
> >> With this patch, both static and shared builds work for me:
> >
> >
> > Confirmed. Works for me too.
> >
> > The only thing that I am a bit concerned about is, why is the HTTP ETag
> > functionality now part of the core, and not part of the http module
> anymore?
> > Isn't this somewhat adverse to other efforts to move more code from core
> to
> > modules?
>
> Despite the directory structure, this was not part of a "module" in
> the httpd/LoadModule sense.  I think it's reasonable to pull it "up"
> which is simpler then trying to push more stuff down into
> modules/http/.
>

[Caviet]
Note that relocation is a major mmn bump, due to two level namespaces...
Which isn't usual apparent on flat namespace architectures such as Linux.

>

Re: https vhosts

[Yann Ylavic]

On Thu, May 24, 2018 at 2:09 PM, Eric Covener  wrote:
>
> Thinking about base server and how scanners report it the "vulnerability"...
>
> AllowUnmatchedHost[name]?
> RejectUnknownHost[name]?

The one or the other is probably a better name than UseDefaultVHost,
it allows to specify it by vhost (really meaningful on base servers
though) OR globally to avoid using fake base servers in the whole
configuration (when relevant).
Looks good to me.

Re: https vhosts

[Eric Covener]

On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing
 wrote:
> Do we have a configuration option to allow https://hostname/ only to matching 
> vhosts without any default fallback?
>
> Scenario:
> - a site with vhost A and B
> - vhost B is taken out, DNS still points there (for a while)
> - browsers opening https://B/ will get the certificate of A and complain
>
> I do not want to present a "wrong" certificate, I want the SSL connection to 
> fail. Does that make sense?

I don't think it exists for SSL or non-SSL today -- you have to
capture them in the first-listed VH for a address/port combo.

Re: Experimental C unit test suite available for hacking

[Eric Covener]

On Thu, May 24, 2018 at 7:23 AM, Micha Lenk  wrote:
> Hi Yann,
>
> On 05/24/2018 12:31 PM, Yann Ylavic wrote:
>>>
>>> Well, first things first. Let's first fix trunk to be buildable again on
>>> build systems that really only link the needed symbols and thus rely on
>>> the
>>> correct library order during linking.
>>
>>
>> I think this is*the*  dependency issue, the order in
>> PROGRAM_DEPENDENCIES should make modules depend on core and not the
>> other way around.
>
>
> Yes, sounds reasonable. With the little knowledge about the build system I
> was just blindly moving library orders around without looking into the
> semantical meaning of these dependencies.
>
>> With this patch, both static and shared builds work for me:
>
>
> Confirmed. Works for me too.
>
> The only thing that I am a bit concerned about is, why is the HTTP ETag
> functionality now part of the core, and not part of the http module anymore?
> Isn't this somewhat adverse to other efforts to move more code from core to
> modules?

Despite the directory structure, this was not part of a "module" in
the httpd/LoadModule sense.  I think it's reasonable to pull it "up"
which is simpler then trying to push more stuff down into
modules/http/.

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

Re: https vhosts

[Stefan Eissing]

> Am 24.05.2018 um 13:28 schrieb Eric Covener :
> 
> On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing
>  wrote:
>> Do we have a configuration option to allow https://hostname/ only to 
>> matching vhosts without any default fallback?
>> 
>> Scenario:
>> - a site with vhost A and B
>> - vhost B is taken out, DNS still points there (for a while)
>> - browsers opening https://B/ will get the certificate of A and complain
>> 
>> I do not want to present a "wrong" certificate, I want the SSL connection to 
>> fail. Does that make sense?
> 
> I don't think it exists for SSL or non-SSL today -- you have to
> capture them in the first-listed VH for a address/port combo.

Which, in case of SSL, needs to present a certificate that does not match and 
browsers issue their "not trustworthy" warnings. Where, in reality (ha, reality 
on the internet!) the site does not exist and it is impossible to make a secure 
connection to it.

So, we are lacking an option here to abort SSL connections without a vhost 
match, it seems. Something like

SSLStrictSNIVHostCheck require-match

?

Re: https vhosts

[Stefan Priebe - Profihost AG]

Hi Stefan,

as i've tried todo nearly the same some weeks ago i can tell you what i did.

Comment inline.

Am 24.05.2018 um 13:34 schrieb Stefan Eissing:
> So, we are lacking an option here to abort SSL connections without a vhost 
> match, it seems. Something like
> 
> SSLStrictSNIVHostCheck require-match

No this will not solve the problem as you may have clients not
supporting sni at all. I tried the same with SSLStrictSNIVHostCheck On

Nowadays those clients see the wrong cert but still land in the correct
vhost container so they "work".

What i did is creating a vhost container which is loaded first in config
order:
1.) Create a fake or general SSL cert (something like a white label cert)
2.) create the container:

  # Because this virtual host is defined first, it will
  # be used as the default if the hostname is not received
  # in the SSL handshake
  ServerName unknown
  DocumentRoot /usr/local/apache/htdocs/

  Protocols h2 http/1.1

  SSLCertificateFile ...
  SSLCertificateKeyFile ...
  SSLCertificateChainFile ...
  SSLEngine on

  ErrorLog /usr/local/apache/logs/htdocs-error.log
  TransferLog /usr/local/apache/logs/htdocs-access.log

  # Rewrite to correct hostname using http - vhost container does not
have https
  RewriteEngine On
  RewriteRule (.*) http://%{HTTP_HOST}/$1 [R=301,L]


Greets,
Stefan

Re: https vhosts

[Eric Covener]

On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing
 wrote:
>
>
>> Am 24.05.2018 um 13:28 schrieb Eric Covener :
>>
>> On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing
>>  wrote:
>>> Do we have a configuration option to allow https://hostname/ only to 
>>> matching vhosts without any default fallback?
>>>
>>> Scenario:
>>> - a site with vhost A and B
>>> - vhost B is taken out, DNS still points there (for a while)
>>> - browsers opening https://B/ will get the certificate of A and complain
>>>
>>> I do not want to present a "wrong" certificate, I want the SSL connection 
>>> to fail. Does that make sense?
>>
>> I don't think it exists for SSL or non-SSL today -- you have to
>> capture them in the first-listed VH for a address/port combo.
>
> Which, in case of SSL, needs to present a certificate that does not match and 
> browsers issue their "not trustworthy" warnings. Where, in reality (ha, 
> reality on the internet!) the site does not exist and it is impossible to 
> make a secure connection to it.
>
> So, we are lacking an option here to abort SSL connections without a vhost 
> match, it seems. Something like
>
> SSLStrictSNIVHostCheck require-match

a more user oriented option:

SSLUseDefaultCertificate OFF|ON
Default: ON
When the server cannot find a matching virtual host for an SSL
request, it will uses the certificate configured in the default
virtual host for an address:port combination. Setting this directive
to OFF will instead { abort the connection, send an alert, halt and
catch fire}.

Re: https vhosts

[Barry Pollard]

> On 24 May 2018, at 12:44, Eric Covener  wrote:
> 
> On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing
>  wrote:
>> 
>> 
>>> Am 24.05.2018 um 13:28 schrieb Eric Covener :
>>> 
>>> On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing
>>>  wrote:
 Do we have a configuration option to allow https://hostname/ only to 
 matching vhosts without any default fallback?
 
 Scenario:
 - a site with vhost A and B
 - vhost B is taken out, DNS still points there (for a while)
 - browsers opening https://B/ will get the certificate of A and complain
 
 I do not want to present a "wrong" certificate, I want the SSL connection 
 to fail. Does that make sense?
>>> 
>>> I don't think it exists for SSL or non-SSL today -- you have to
>>> capture them in the first-listed VH for a address/port combo.
>> 
>> Which, in case of SSL, needs to present a certificate that does not match 
>> and browsers issue their "not trustworthy" warnings. Where, in reality (ha, 
>> reality on the internet!) the site does not exist and it is impossible to 
>> make a secure connection to it.
>> 
>> So, we are lacking an option here to abort SSL connections without a vhost 
>> match, it seems. Something like
>> 
>> SSLStrictSNIVHostCheck require-match
> 
> a more user oriented option:
> 
> SSLUseDefaultCertificate OFF|ON
> Default: ON
> When the server cannot find a matching virtual host for an SSL
> request, it will uses the certificate configured in the default
> virtual host for an address:port combination. Setting this directive
> to OFF will instead { abort the connection, send an alert, halt and
> catch fire}.

Sorry for butting in but I’d personally prefer an option like this:

AllowConnections off

Or

DropConnection on

Think that is more flexible as that way you could disable some specific hosts 
and leave the default there. Or you could have the default as off. This would 
also allow you to do the same for HTTP sites.

Re: https vhosts

[Yann Ylavic]

On Thu, May 24, 2018 at 1:44 PM, Eric Covener  wrote:
> On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing
>  wrote:
>>
>>
>>> Am 24.05.2018 um 13:28 schrieb Eric Covener :
>>>
>>> On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing
>>>  wrote:
 Do we have a configuration option to allow https://hostname/ only to 
 matching vhosts without any default fallback?

 Scenario:
 - a site with vhost A and B
 - vhost B is taken out, DNS still points there (for a while)
 - browsers opening https://B/ will get the certificate of A and complain

 I do not want to present a "wrong" certificate, I want the SSL connection 
 to fail. Does that make sense?
>>>
>>> I don't think it exists for SSL or non-SSL today -- you have to
>>> capture them in the first-listed VH for a address/port combo.
>>
>> Which, in case of SSL, needs to present a certificate that does not match 
>> and browsers issue their "not trustworthy" warnings. Where, in reality (ha, 
>> reality on the internet!) the site does not exist and it is impossible to 
>> make a secure connection to it.
>>
>> So, we are lacking an option here to abort SSL connections without a vhost 
>> match, it seems. Something like
>>
>> SSLStrictSNIVHostCheck require-match
>
> a more user oriented option:
>
> SSLUseDefaultCertificate OFF|ON
> Default: ON
> When the server cannot find a matching virtual host for an SSL
> request, it will uses the certificate configured in the default
> virtual host for an address:port combination. Setting this directive
> to OFF will instead { abort the connection, send an alert, halt and
> catch fire}.

That'd work (and looks better than Stefan's SNI oriented proposal),
but I wish we had something working for non-SSL vhosts too,
UseDefaultVHost OFF|ON?

Re: https vhosts

[Stefan Eissing]

> Am 24.05.2018 um 13:43 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Stefan,
> 
> as i've tried todo nearly the same some weeks ago i can tell you what i did.

:-) In the era of DGSVO, some sites simply wish to disappear silently...

> Comment inline.
> 
> Am 24.05.2018 um 13:34 schrieb Stefan Eissing:
>> So, we are lacking an option here to abort SSL connections without a vhost 
>> match, it seems. Something like
>> 
>> SSLStrictSNIVHostCheck require-match
> 
> No this will not solve the problem as you may have clients not
> supporting sni at all. I tried the same with SSLStrictSNIVHostCheck On
> 
> Nowadays those clients see the wrong cert but still land in the correct
> vhost container so they "work".
> 
> What i did is creating a vhost container which is loaded first in config
> order:
> 1.) Create a fake or general SSL cert (something like a white label cert)
> 2.) create the container:
> 
>  # Because this virtual host is defined first, it will
>  # be used as the default if the hostname is not received
>  # in the SSL handshake
>  ServerName unknown
>  DocumentRoot /usr/local/apache/htdocs/
> 
>  Protocols h2 http/1.1
> 
>  SSLCertificateFile ...
>  SSLCertificateKeyFile ...
>  SSLCertificateChainFile ...
>  SSLEngine on
> 
>  ErrorLog /usr/local/apache/logs/htdocs-error.log
>  TransferLog /usr/local/apache/logs/htdocs-access.log
> 
>  # Rewrite to correct hostname using http - vhost container does not
> have https
>  RewriteEngine On
>  RewriteRule (.*) http://%{HTTP_HOST}/$1 [R=301,L]
> 


I thought about this. In case of a general hoster, redirecting to a business 
site which explains like "this domain is no longer hosted here, blabla", makes 
sense.

In my case, a site "disappeared" that is in no way affiliated with the other 
vhosts and I would like to avoid the impression that it is. Sure, people who 
know DNS and IP addresses, can easily find co-located sites, but that is 
another level.

-Stefan

Re: https vhosts

[Stefan Eissing]

Personally, I am looking for an option where I do not have to keep "old" vhosts 
around.

Also, I would like to avoid that someone points "beastlovers.net" to my ip 
address and
people get the greenbytes.de homepage when follwing some spam/phishing mails 
(this is
a theoretical thread model, rest assured).

-Stefan

> Am 24.05.2018 um 13:50 schrieb Barry Pollard :
> 
> 
> 
>> On 24 May 2018, at 12:44, Eric Covener  wrote:
>> 
>> On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing
>>  wrote:
>>> 
>>> 
 Am 24.05.2018 um 13:28 schrieb Eric Covener :
 
 On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing
  wrote:
> Do we have a configuration option to allow https://hostname/ only to 
> matching vhosts without any default fallback?
> 
> Scenario:
> - a site with vhost A and B
> - vhost B is taken out, DNS still points there (for a while)
> - browsers opening https://B/ will get the certificate of A and complain
> 
> I do not want to present a "wrong" certificate, I want the SSL connection 
> to fail. Does that make sense?
 
 I don't think it exists for SSL or non-SSL today -- you have to
 capture them in the first-listed VH for a address/port combo.
>>> 
>>> Which, in case of SSL, needs to present a certificate that does not match 
>>> and browsers issue their "not trustworthy" warnings. Where, in reality (ha, 
>>> reality on the internet!) the site does not exist and it is impossible to 
>>> make a secure connection to it.
>>> 
>>> So, we are lacking an option here to abort SSL connections without a vhost 
>>> match, it seems. Something like
>>> 
>>> SSLStrictSNIVHostCheck require-match
>> 
>> a more user oriented option:
>> 
>> SSLUseDefaultCertificate OFF|ON
>> Default: ON
>> When the server cannot find a matching virtual host for an SSL
>> request, it will uses the certificate configured in the default
>> virtual host for an address:port combination. Setting this directive
>> to OFF will instead { abort the connection, send an alert, halt and
>> catch fire}.
> 
> Sorry for butting in but I’d personally prefer an option like this:
> 
> AllowConnections off
> 
> Or
> 
> DropConnection on
> 
> Think that is more flexible as that way you could disable some specific hosts 
> and leave the default there. Or you could have the default as off. This would 
> also allow you to do the same for HTTP sites.
> 
> 

Re: https vhosts

[Stefan Eissing]

> Am 24.05.2018 um 13:51 schrieb Yann Ylavic :
> 
> On Thu, May 24, 2018 at 1:44 PM, Eric Covener  wrote:
>> On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing
>>  wrote:
>>> 
>>> 
 Am 24.05.2018 um 13:28 schrieb Eric Covener :
 
 On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing
  wrote:
> Do we have a configuration option to allow https://hostname/ only to 
> matching vhosts without any default fallback?
> 
> Scenario:
> - a site with vhost A and B
> - vhost B is taken out, DNS still points there (for a while)
> - browsers opening https://B/ will get the certificate of A and complain
> 
> I do not want to present a "wrong" certificate, I want the SSL connection 
> to fail. Does that make sense?
 
 I don't think it exists for SSL or non-SSL today -- you have to
 capture them in the first-listed VH for a address/port combo.
>>> 
>>> Which, in case of SSL, needs to present a certificate that does not match 
>>> and browsers issue their "not trustworthy" warnings. Where, in reality (ha, 
>>> reality on the internet!) the site does not exist and it is impossible to 
>>> make a secure connection to it.
>>> 
>>> So, we are lacking an option here to abort SSL connections without a vhost 
>>> match, it seems. Something like
>>> 
>>> SSLStrictSNIVHostCheck require-match
>> 
>> a more user oriented option:
>> 
>> SSLUseDefaultCertificate OFF|ON
>> Default: ON
>> When the server cannot find a matching virtual host for an SSL
>> request, it will uses the certificate configured in the default
>> virtual host for an address:port combination. Setting this directive
>> to OFF will instead { abort the connection, send an alert, halt and
>> catch fire}.
> 
> That'd work (and looks better than Stefan's SNI oriented proposal),
> but I wish we had something working for non-SSL vhosts too,
> UseDefaultVHost OFF|ON?

Could work also, if this means that SSL connections with SNI are then
aborted right away. As explained, I do want such hosts to simply not
work with https:, and avoid a "not secure" warning first.

-Stefan