git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exposing SSL certificates on SNI mismatch


On Fri, Nov 9, 2018 at 2:03 AM Ruediger Pluem <rpluem@xxxxxxxxxx> wrote:

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.

IIRC, this is a feature Stefan brought up recently... silently terminating SSL
handshakes which don't follow expected SNI patterns, without a bunch of
info/warn associated log entries (perhaps without a log entry.)

However, the proposal above seems entirely silly. The information being
"guarded" from other vhost logs is publicly available to all through DNS.
But I think it is possible today. Prior to all other Vhost blocks, add...

<VirtualHost <shared ip>:80>
   ServerName nomatch.example.tld
   ...
</VirtualHost>
 
<VirtualHost <shared ip>:443>
   ServerName nomatch.example.tld
   SSLCertificateFile <...self-signed certificate file with a non-matching hostname>
   ...
</VirtualHost>

All requests which don't match the later server names/SNI certs will
be handled through these garbage collection hosts. You can redirect
to a status 400 bad request response or anything you like, collecting
the error logs outside the scope of per-domain access/error logs.

The first matching vhost block is used when no ServerName/ServerAlias
matches are found.