服务器名称指示 (SNI)是一个 TLS 扩展，它允许 TLS 客户端指示它正在尝试访问的主机。这对于具有虚拟主机（即从一个盒子托管多个域）的 Web 服务器很重要，以便它们可以决定返回哪个证书。通常通过HostHTTP 标头检测目标虚拟主机，但在构建 TLS 隧道之前无法发送。SNI 允许 TLS 客户端指示名称，以便在进行基础 HTTP 调用之前可以提供正确的证书。大多数 TLS 服务器的另一个特性是 SNI 可用于在已为每个虚拟主机配置的不同 TLS 配置之间进行选择。

由于您现在有两个指示您尝试访问的主机（SNI 和主机标头），如果您强制它们不匹配，可能会出现奇怪的行为。现在，假设您有一个使用 HTTPS 的站点，还有一个管理子域，并且它们都托管在同一台服务器上。管理子域在 SNI 配置级别被锁定，因此它需要客户端证书。这意味着常规站点使用仅运行正常 HTTPS，但您需要客户端证书才能连接到管理子域。

但是，如果您要在 SNI 指向主域但 Host 标头指向管理子域的情况下发出请求，则可以在没有客户端证书的情况下构建 TLS 隧道（因为使用了主站点的规则）但是 Web服务器可能会像您连接到管理子域一样提供内容。这可以让您绕过该客户端证书限制。

错误阻止了什么样的漏洞或攻击媒介？

这种攻击被称为“虚拟主机混淆”， 2014 年有几个 CDN 被发现容易受到攻击。主要思想是可以利用 TLS 握手中的目标名称（“通过 SNI 提供”）和 HTTP 协议中的目标名称（“通过 HTTP 提供”）之间的不匹配。根据服务器的设置，它可能用于模拟他人拥有的 HTTPS 站点，也可用于窃取会话 cookie 等。

有关更多信息，请阅读“针对 HTTPS 虚拟主机的基于网络的源混淆攻击”一文，阅读HackerOne 上的信息，观看有关此攻击如何帮助“使用 Akamai 绕过互联网审查”的视频，或观看 Blackhat 2014上的演讲这和其他针对 TLS 的攻击已经证明。

如果您有一个轻量级前端使用 SNI 跨不同 HTTPS 服务器分派请求的设置，则 Apache 执行的额外检查可防止无效请求被用于访问原本无法访问的内容。

由于 SNI 字段在服务器发送任何内容之前由客户端发送的 TLS 客户端问候消息中，因此可以构建一个轻量级前端，它对 HTTP 和 TLS 知之甚少，但仍然能够将 TLS 连接分派到不同的后端取决于主机名。

这样的前端只需要知道足够的 TLS 即可解析客户端 hello 消息并提取主机名。一旦有了它，它就可以将所有未修改的数据传递到单独的 HTTPS 后端。只有后端需要建立 TLS 连接所需的服务器密钥。

在此设置中，前端将永远无法知道 HTTP 主机标头中发送的主机名，因为它无法解密流量。因此，这样的前端不可能比较两个主机名。

即使 HTTPS 服务器本身对 SNI 一无所知，此设置确实允许在单个 IP 地址后面托管多个域。但是，如果 HTTPS 服务器对 SNI 一无所知，则客户端可能会发送损坏的请求，其中前端和后端会看到同一 HTTPS 请求的两个不同主机名。

可以配置前端和后端，使得某个虚拟主机只能通过告诉前端和后端不同的主机名来访问。

如果对于每个有效的 HTTPS 请求都无法访问虚拟主机，则如果可以通过发送无效的 HTTPS 请求来访问该虚拟主机，则可以合理地将其视为漏洞。如果后端是支持 SNI 的 Apache 版本，则您询问的检查将防止该漏洞。