39

Earlier today, Lone Learner asked Why is there no certificate error while visiting google.net although it presents a certificate issued to google.com?

The accepted answer explains that the issue was caused by an SNI Hole.

You've fallen into a "SNI hole". Google will present a different certificate if there is no "Server Name Indication" given in the client's TLS handshake part.
-StackzOfZtuff

The top search result for "What is an SNI Hole" is the question page for What are the security implications of enabling a SNI-hole on a web server?, which isn't much help for those unfamiliar with the term.

What exactly is an SNI Hole?

Stevoisiak
  • 1,515
  • 1
  • 11
  • 27
  • 1
    I gave a bit more detail in an [answer from 2015](https://serverfault.com/a/726292/253701). – StackzOfZtuff Jul 10 '17 at 21:09
  • 1
    Since there are already several good answers here, I'll just add that I called it a [SNI-hole](https://security.stackexchange.com/q/91717/78662) in my original question because I couldn't find any references to that sort of SSL configuration and I needed a concise way to describe it in the question title. SNI/TLS developers may have a different term for it. – Parker Jul 12 '17 at 01:42

3 Answers3

37

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.

Michael
  • 2,391
  • 2
  • 19
  • 36
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Not just error messages - its possible to host entire services this way. At the time I wrote the question, there were several new vulnerabilities out that created a mutually-exclusive set of supportable clients (in order for Chrome to connect to our site, we would have needed to disable support for older clients). With a SNI hole, I could maintain a legacy HTTPS API for old web clients (Java 5/6, IE6-8) without compromising newer clients. Old clients fall through to the default host (deprecated cipher suites), while newer clients connect to the Server Indicated by Name (modern cipher suites). – Parker Jul 12 '17 at 01:52
  • @vallismortis: It's not clear for me what you are referring to with *"Not just error messages"*. I showed three ways the server will typically react: sending error back (in the TLS handshake, i.e. TLS alert), simply closing the connection or using a default certificate. And the last option of using a default certificate of course makes it possible to continue with the TLS handshake and thus offer any service after the handshake is done as long as the client accepts the certificate. – Steffen Ullrich Jul 12 '17 at 05:34
  • @Steffen-Ulrich This isn't about a "default certificate" - the cipher suites and SSL protocols may also be configured differently on the default host while using the same SSL certificate. Even the same certificate can be set up differently, with different sized DH keys, or chains to different certificate roots. Yes, you could offer a different certificate entirely, but in my experience that has been unnecessary. – Parker Jul 12 '17 at 12:05
  • @vallismortis: I don't see how this comment is related to the question. The suites and protocols can in theory be different for each certificate the server offers because the decision which certificate and which cipher and protocol gets used is done after receiving the initial ClientHello. This has nothing to do specifically with SNI hole. – Steffen Ullrich Jul 12 '17 at 12:43
  • @Steffen-Ulrich You presented a very narrowly defined use case for a SNI hole that is based on serving different certificates to clients. There is a broader utility in using the same certificate to support deprecated protocols and cipher suites for older clients. – Parker Jul 12 '17 at 13:01
  • @vallismortis: I see now what you mean. But, I did not intend to present any use cases at all and I don't believe that I actually did. I've only described the ways servers typically react if SNI is not used and thus it is unknown which certificate is needed by the client. You can use SNI hole to detect older clients but you could also use the offered cipher set and protocol versions for this - with much better granularity. – Steffen Ullrich Jul 12 '17 at 13:06
  • @Steffen-Ulrich In most cases, yes, the offered cipher suite and protocols can be used for Secure Renegotiation. However, there are some clients (i.e., Chrome) that will refuse to establish a connection if it sees an SSL protocol that it doesn't like. The SNI hole is a way of hiding obsolete protocols from modern browsers while offering them to older clients (especially on older mobile devices). Sorry to drag out the conversation here - I didn't have any problem with your answer, but I wanted to show the real utility of this type of server configuration, and why it may be seen in the wild. – Parker Jul 12 '17 at 13:43
  • @vallismortis: there is no renegotiation needed. The initial ClientHello contains all information about the best TLS protocol version supported by the client, the supported ciphers and the hostname it expects the certificate for (if SNI is used). This will be used by the server to choose the common cipher, TLS protocol and certificate to serve. No SNI hole and no renegotiation are needed for this. – Steffen Ullrich Jul 12 '17 at 14:31
11

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.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • And I thought the one-IP/port-per-certificate was just a Microsoft thing that they finally fixed with IIS 8... You're saying that HTTPS was built that way? – Michael Jul 11 '17 at 20:31
  • 3
    @Michael Yes, that was an OS-independent problem. Apache-on-unix administrators had to have an IP address per certificate too. Go back a little further, before HTTP 1.1 made the Host header mandatory, and you had to have an IP address per hostname even without SSL. –  Jul 12 '17 at 01:24
1

You contacted a SNI server that actually has more than one SSL domain with a non-SNI client. The server guessed wrong.

Same basic story when contacting a HTTP/1.1 server with a HTTP/1.0 client. The server guesses.

Joshua
  • 1,090
  • 7
  • 11