http2：421 Misdirected Request Status Code 示例

Question

我正在阅读spec 并试图准确了解何时可能返回 421。举了一个例子，但我不完全明白。

背景

规范建立了两个允许连接重用的条件：

对于没有 TLS 的 TCP 连接，这取决于解析到相同 IP 地址的主机。

和

对于 https 资源，连接重用另外取决于拥有一个 对 URI 中的主机有效的证书。

如果连接中使用的证书有多个subjectAltName 或任何subjectAltName 是通配符，则可以将连接重新用于具有在subjectAltNames 列表中的主机名的任何请求或匹配任何通配符。

规范中的具体示例

在某些部署中，为多个源重用连接可以 导致请求被定向到错误的源服务器。为了 例如，TL​​S 终止可能由一个中间盒执行，该中间盒使用 TLS 服务器名称指示 (SNI) [TLS-EXT] 扩展以选择一个 源服务器。这意味着客户端可以发送 向服务器发送的机密信息可能不是预期的 请求的目标，即使服务器不是 权威。

请解释我对这个例子的理解是错误的：

与具有域x.com 的请求的中间盒建立https 连接。中间盒的 IP 地址为 1.2.3.4，x.com 解析为该地址。使用 SNI，TLS 握手具有x.com，并且中间盒返回对该域有效的证书。此连接上的所有消息都从客户端发送到中间盒或从中间盒发送到客户端。从客户端到中间盒的应用程序级消息由中间盒转发到不同连接上的源。从源到中间盒的消息被转发到客户端。如果要重用连接，满足上面讨论的两个条件是不够的。具体来说，对于域 y.com 的请求：如果 y.com 解析为 1.2.3.4 并且中间盒具有对 y.com 有效的证书，则仍然可能存在问题。因为原始连接使用x.com 进行了它的TLS 握手，并且因为握手只在新连接开始时完成，所以无法建立一个可以获得y.com 证书的https 连接。因此客户端错误地将同一连接上的请求发送到y.com。中间盒拒绝该请求，因为与连接关联的证书对x.com 有效，而不是y.com。 （x.com证书只对x.com有效，y.com证书只对y.com有效。

Answer 1

据我所知，您的所有示例都不会触发 421。

是的，您是正确的，连接需要同时证书中的 IP 地址和 SAN 字段才有效 - 如果没有这些，则不应重复使用连接。

那么什么会触发 421？据我所知，这主要是由于不同的 SSL/TLS 设置。

例如： 假设网站 A (siteA.example.com) 和网站 B (www.example.com) 都在同一个 IP 地址上。假设网站 A 有一个 *.example.com 的通配符证书，而网站 B 有一个特定的证书。这可能有几个原因：例如，它为不能是通配符证书的主网站提供 EV 证书。

所以证书 A 涵盖网站 A 和网站 B。IP 地址也是如此。因此，如果您连接到网站 siteA.example.com，然后尝试连接到 www.example.com，那么从技术上讲，按照 HTTP/2 标准，您可以重用该连接。但我们不希望这种情况发生，因为我们想使用我们的 EV 证书。所以服务器应该用 421 拒绝。现在在这个例子中，网络服务器能够区分正确的主机并且拥有该主机的有效证书，因此理论上可以在通配符证书下提供正确的内容，而不是发送 421 - 但由于没有为该虚拟主机定义通配符证书，因此不应该这样做。

其他示例包括您是否在不同的主机上设置了不同的密码。例如，站点 A 具有超级宽松的 HTTPS 配置，因为它不是真正安全的内容，他们甚至希望访问旧版浏览器，但站点 B 具有超级安全的配置，并且只接受最新的 TLS 版本和强密码。在这里，您显然不希望他们重用相同的连接细节。请参阅here 了解这方面的真实示例。

此外，这只是某些浏览器的问题，具体取决于它们决定连接共享的方式。这个页面展示了他们每个人在这方面的不同之处（至少在这篇博文发布时不知道从那时起有什么变化）：https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

另外请注意，这会存在一些错误（例如：https://bugs.chromium.org/p/chromium/issues/detail?id=546991）。最佳建议是：如果您不希望发生连接共享，请使用不同的 IP 地址和/或确保证书没有重叠。