On 11/08/2018 09:23 AM, Micha Lenk wrote:
> Hi all,
>
> I have a customer asking about whether the SSL handshake can be made to fail
> in case the SNI from the "Client Hello"
> message doesn't match at all any server name of the configured virtual hosts.
> E.g. consider a setup like this
>
> DNS records:
> domain-a.tld resolves to <shared ip>
> domain-b.tld also resolves to <shared ip>
>
> Listen <shared ip>:443 https
> Listen <shared ip>:80 http
>
> <VirtualHost <shared ip>:80>
> ServerName domain-a.tld
> ...
> </VirtualHost>
>
> <VirtualHost <shared ip>:80>
> ServerName domain-b.tld
> </VirtualHost>
>
> <VirtualHost <shared ip>:443>
> ServerName domain-b.tld
> SSLEngine On
> SSLCertificateFile <...a certificate file only valid for domain-b.tld>
> ...
> </VirtualHost>
>
> I.e. no virtual host with SSL enabled for domain-a.tld exists.
>
> In this setup the customer wants the server to not expose the SSL certificate
> of other, unrelated virtual hosts in case
> a client/browser tries to access https:/domain-a.tld/ (which isn't configured
> in Apache).
>
> Is this currently possible? If yes, in 2.4.x or only trunk?
>
> I remember a discussion thread of this topic floating by, but I can't find it
> anymore. Does anybody else maybe have a
> pointer to some public mail archive?
>
> Thanks a lot in advance for any comment,
Currently there is no possibility to block this. You will only see AH02044 if
the loglevel is set to debug in this case.
But I guess in the code block of the logmessage you could handle this by
aborting the connection if a (new)
configuration flag is set.
Regards
RĂ¼diger