What security impact is caused by a TLS server continuing the handshake when presented with an invalid SNI?

Question

RFC 6066 defines Server Name Indication as an extension, whereby virtualised web servers may be given an SNI extension in order to know which certificate should be presented.

It has the following to say about cases where the indicated server name does not match a known name (emphasis mine):

If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake. It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable. If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication. TLS implementations are encouraged to make information available to application callers about warning- level alerts that were received or sent during a TLS handshake. Such information can be useful for diagnostic purposes.

What is the potential security impact of continuing the handshake when an invalid SNI is sent? I'm particularly thinking about cases where an entirely different domain is provided, or an incorrect subdomain. What is the compatibility rationale behind not rejecting such requests? My limited testing showed that sending "microsoft.com" in the SNI field to a TLS service on google.com didn't reject my content, whereas doing the same to a CloudFlare-enabled service caused the fatal alert.

Answer 1

There is no security impact to either stop or continue the handshake -- the security relies in the tests performed by the client, not the server. This is why the extension is called an indication. What matters is that the client duly verifies that the apparent server public key is really owned by the intended server. The SNI is a way for the client to convey to the server a hint about the process that the client will use for that verification: namely, the client will check that the server's certificate is valid, and that it identifies a specific server name.

Even if the server sees that the SNI matches its own certificate, the client still has to do all checks.

In case of SNI mismatch (the client sends a name for which the server has no matching certificate), keeping on with the handshake can be somewhat useful in order to send an explicit error message. The human user, on the client side, will have to "click through" the warning, and human users should really be trained not to do that, but if they do, then they may see a page sent by the server that will state exactly that ("This is not the Web site you are looking for"). With an SSL-level alert, all the user will see will be the generic "Could not connect, check your Internet connection" that is awfully uninformative.