lf2*_*215 2 http-status-codes http2 http-status-code-421
我正在阅读规范并试图准确了解 421 何时可能返回。给出了一个例子,但我不完全理解它。
背景
该规范建立了两个允许连接重用的条件:
对于没有 TLS 的 TCP 连接,这取决于解析为相同 IP 地址的主机。
和
对于 https 资源,连接重用还取决于是否拥有对 URI 中的主机有效的证书。
如果连接中使用的证书有多个subjectAltName或其中任何一个subjectAltName是通配符,则该连接可以重新用于主机名位于 s 列表中subjectAltName或与任何通配符匹配的任何请求。
规范中的具体示例
在某些部署中,重复使用多个源的连接可能会导致请求被定向到错误的源服务器。例如,TLS 终止可能由使用 TLS 服务器名称指示 (SNI) [TLS-EXT] 扩展来选择源服务器的中间件执行。这意味着客户端有可能将机密信息发送到可能不是请求的预期目标的服务器,即使该服务器在其他方面具有权威性。
请解释一下我对这个例子的理解哪里错误:
使用具有域的请求建立到中间件的 https 连接x.com。中间盒的 IP 地址为 1.2.3.4,并x.com解析为该地址。使用 SNI,TLS 握手会x.com返回一个对该域有效的证书。此连接上的所有消息都从客户端发送到中间件或从中间件发送到客户端。从客户端到中间件的应用程序级消息由中间件转发到不同连接上的源。从源到中间盒的消息被转发到客户端。如果要重用连接,满足上面讨论的两个条件是不够的。具体来说,对于域为 的请求y.com:如果y.com解析为 1.2.3.4 并且中间件具有对 有效的证书y.com,则仍然可能存在问题。因为原始连接使用 TLS 握手x.com,并且握手仅在新连接开始时完成,所以无法建立 https 连接来获取y.com. 因此客户端错误地在同一连接上向 发送请求y.com。中间件拒绝请求,因为与连接关联的证书的有效期为x.com- not y.com。(该x.com证书仅适用于x.com且该y.com证书仅适用于y.com)。
据我所知,你的例子都不会触发 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 版本和强密码。在这里,您显然不希望他们重复使用相同的连接详细信息。请参阅此处的真实示例。
此外,这只是某些浏览器的问题,具体取决于它们决定连接共享的方式。此页面显示了他们每个人的做法有何不同(至少在这篇博客文章发表时不知道此后发生的任何变化):https ://daniel.haxx.se/blog/2016/08/18/http2-连接合并/
另请注意,此操作会存在一些错误(例如: https: //bugs.chromium.org/p/chromium/issues/detail ?id =546991)。最好的建议是:如果您不希望发生连接共享,请使用不同的 IP 地址和/或确保证书中没有重叠。
| 归档时间: |
|
| 查看次数: |
8588 次 |
| 最近记录: |