What is an SNI Hole?

SNI (Server Name Indication) is a TLS (Transport Layer Security) extension in which the client presents the server the domain name for the target it wants to access within the TLS handshake. It is used in cases where there are multiple virtual servers with different certificates on the same IP address, so that the server can present the correct certificate.

Insofar it is similar to the HTTP host header in the HTTP request, which is used to select the matching virtual host configuration - only the Host header cannot be used to select the certificate since it is sent inside the HTTP request. (i.e. after the TLS handshake is already done).

Since the SNI TLS extension is optional, some clients may not send this extension. This is the case with openssl s_client without the -servername argument, but also with many TLS libraries in different programming languages. And while all modern browsers use SNI, older browsers like IE8 on XP do not use it.

If such a client connects to a server which has multiple certificates, the server does not know which certificate the client actually needs, i.e. the client falls into the "SNI hole" by not using the SNI extension. In this case the server usually either sends an error back (or sometimes just closes the connection) or uses a default certificate explicitly or implicitly configured for this purpose.

An SNI hole is when you have a default site set up for an IP address that does not require SNI to be present in order to complete an HTTPS connection.

This is, in fact, how all HTTPS connections used to work, before SNI existed. Each HTTPS site required a routable IP address, not just a hostname. So, when set up this way, any port 443 request to that IP address will resolve to that one site, even if you have many HTTP (port 80) sites using virtual hostnames. This was a perennial problem for people who reused webservers for a number of sites, and then decided to set up SSL/HTTPS for one. If you're running http://example.com and http://contoso.com on the same server, and then set up HTTPS for example.com, results for http://contoso.com will still work correctly, but requests for https://contoso.com will return results from https://example.com, albeit with a certificate error.

What's you're seeing here is effectively the same thing. If you don't send the SNI extension telling Google's servers what hostname you're trying to connect to, the default for the Google webserver IP addresses is the google.com site, so regardless of which hostname you're trying to connect to, it will be google.com that will respond.