On Thu, May 24, 2018 at 7:51 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
> On Thu, May 24, 2018 at 1:44 PM, Eric Covener <cove...@gmail.com> wrote:
>> On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing
>> <stefan.eiss...@greenbytes.de> wrote:
>>>
>>>
>>>> Am 24.05.2018 um 13:28 schrieb Eric Covener <cove...@gmail.com>:
>>>>
>>>> On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing
>>>> <stefan.eiss...@greenbytes.de> 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.

Reply via email to