Re: https vhosts

[William A Rowe Jr]

First off, I need to call this out to point you to folks who have walked
this path before; https://bz.apache.org/bugzilla/show_bug.cgi?id=56241

That said, our "radically pedantic" switch with HttpProtocolOptions Strict
inflicts such changes on users. Some will be unhappy, but if they serve
the constraints of the host, it isn't our job to accommodate every case of
misrouted traffic or misimplemented clients.

Looking at the gawdawful list of SSL directives, it is overtime to finally
implement [TLS|SSL]ProtocolOptions directive (not really SSLOptions,
as those doesn't alter the protocol at all.) There are a half or baker's
dozen of directives that were simply toggles, and should have been
rolled into a single protocol behavior description.

On Fri, May 25, 2018 at 3:34 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:

>
> > Am 24.05.2018 um 14:22 schrieb 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.
>
> Like it. For simplicity, I think it should only be global.
>

-1; this has physical vhost scope... What you do on an internally bound
monitoring / internal consumers / routed external / or outward facing
traffic can all behave quite differently with legitimate purpose. Clients
can't send an SNI with a by-IP "name". This is fine to prevent external
abuse but breaks many examples/tutorials.


> Using it in the first vhost has the same effect. Using it
> in a subsequent vhost will have no effect. Does not really make sense, or?
>

We get it, when NameVirtualHost was removed, people got confused. But the
first matching phys vhost continues to control across mod_ssl, http, http2,
etc etc. Admins need to learn this difference to understand how their
config behaves. If our docs don't get this right, shame on us (but I think
they do).

It would be cool to actually flag those directives which are exclusive to
physical vhosts, and not applicable after named vhost routing. We could
amplify the signal from debug -> info -> warning to caution admins that
their config never did what they expected it would.

So, proposal:
>
> RejectUnknownHosts [ on | off ]   (Default: off)
>
> as core directive.
>

I see three possible behaviors; treat as a physical vhost match (today's
behavior), fall out to global match, or reject.

There is another possibility, in the much longer term. Demand users to use
ServerAlias * to clearly indicate their preferred default vhost, treat the
absence as a fall-back to global, which can be easily configured to reject
everything or serve a diagnostic to admins.

So, we are proposing (my reading) that any protocol module can inspect and
react to this directive. So this would be implemented at the core, and in
mod_ssl (perhaps again in h2?) and any other connection or request handler?

Core http would respond 400 Bad Request (connection: close), with almost no
response headers. [If we were to define a new error, because a fitting one
doesn't exist, I'd title the RFC Dave's Not Here, a Cheech and Chong joke
corresponding to Twitter's 420 response.]

Before this, mod_ssl used to respond SSL_TLSEXT_ERR_NOACK, so this is
simply a transition to SSL_TLSEXT_ERR_ALERT_FATAL in the unrecognized SNI
hostname case.

I'd prefer that the SSL fatal no-handshake toggle lives in an
SSLProtocolOptions and we migrate all those binary/tristate decisions to
one place. Absent this flag, your example still fails at the http layer
with an http 400 response.



> For mod_ssl, it would be good to move its "ssl_find_vhost()" partially
> into the core. We could add a method
>
> AP_DECLARE(server_rec *) ap_vhost_find_server(conn_rec *c, const char
> *hostname);
>
> that returns the match, the base or NULL if rejected. That would remove
> parts of the vhost matching implementation in mod_ssl and we would not
> need to expose the core config.
>
> WDYT?
>

Note that semantics matter; our name matching is not TLS's matching, but I
don't believe the function above is moving SSL functionality into core, it
is more one of returning core functionality to core from mod_ssl. But it
must behave identically to our lookup code IMO, so a mismatch still returns
to the phys server_rec in this version of httpd.

Re: https vhosts

[Stefan Eissing]

> Am 24.05.2018 um 14:22 schrieb 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.

Like it. For simplicity, I think it should only be global. 

Using it in the first vhost has the same effect. Using it 
in a subsequent vhost will have no effect. Does not really make sense, or?

So, proposal:

RejectUnknownHosts [ on | off ]   (Default: off)

as core directive.

For mod_ssl, it would be good to move its "ssl_find_vhost()" partially
into the core. We could add a method

AP_DECLARE(server_rec *) ap_vhost_find_server(conn_rec *c, const char 
*hostname);

that returns the match, the base or NULL if rejected. That would remove 
parts of the vhost matching implementation in mod_ssl and we would not
need to expose the core config.

WDYT?

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

[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

[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

[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: 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

[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

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: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

[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

[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

[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

[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

[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

[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.

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