http2:421错误定向的请求状态代码示例 [英] http2: The 421 Misdirected Request Status Code example
问题描述
我正在阅读规范，并试图确切地了解何时可能是421回.给出了一个例子，但我并不完全理解.
I'm reading the spec and trying to understand exactly when 421 might be returned. An example is given but I don't completely understand it.
背景
规范建立了两个条件，允许连接重用:
The spec establishes two conditions that allow for connection reuse:
对于不带TLS的TCP连接，这取决于主机已解析为相同的IP地址.
For TCP connections without TLS, this depends on the host having resolved to the same IP address.
和
对于https资源，另外连接的重用取决于是否有一个对URI中的主机有效的证书.
For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.
如果在连接中使用的证书具有多个 subjectAltName 或任何 subjectAltName 是通配符，则该连接可重新用于具有以下主机名的任何请求:在 subjectAltName 的列表中或与任何通配符匹配.
If the certificate used in the connection has multiple subjectAltName or any of the subjectAltName is a wildcard, then the connection can be reused for any request that has a hostname that is in the list of subjectAltNames or matches any of the wildcards.
规范中的特定示例
在某些部署中，将连接重用于多个来源可以导致请求被定向到错误的原始服务器.为了例如，TLS终止可能由使用TLS服务器名称指示(SNI)[TLS-EXT]扩展名以选择一个原始服务器.这意味着客户可以发送向服务器发送的机密信息可能不是预期的请求的目标，即使服务器不在此范围内权威.
In some deployments, reusing a connection for multiple origins can result in requests being directed to the wrong origin server. For example, TLS termination might be performed by a middlebox that uses the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an origin server. This means that it is possible for clients to send confidential information to servers that might not be the intended target for the request, even though the server is otherwise authoritative.
请解释我对本示例的理解有误的地方:
与具有域 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握手，并且由于握手仅在新连接的开始进行，因此无法建立https连接来获取 y的证书.com .因此，客户端会在与 y.com 相同的连接上错误地发送请求.中间盒拒绝该请求，因为与该连接关联的证书对 x.com 有效-对 y.com 有效.( x.com 证书仅对 x.com 有效，而 y.com 证书仅对 y.com有效).
An https connection is established to a middlebox with a request that has domain x.com. The middlebox has IP address 1.2.3.4 and x.com resolves to that address. Using SNI, the TLS handshake has x.com and the middlebox returns a certificate valid for that domain. All messages on this connection go from the client to the middlebox or from middlebox to client. Applicaiton level messages from client to middlebox are forwarded by middlebox to an origin on a different connection. Messages from origin to middlebox are forwarded to the client. If the connection is to be reused, meeting the two conditions discussed above is not enough. Specifically, for a request with domain y.com: if y.com resolves to 1.2.3.4 and the middlebox has a certificate valid for y.com, there can still be a problem. Because the original connection did its TLS handshake using x.com and because handshakes are only done at the beginning of new connections, there is no way establishing an https connection that would get the certificate for y.com. So the client incorrectly sends a request on the same connection to y.com. The middlebox rejects the request because the certificate associated with the connection is valid for x.com - not y.com. (The x.com certificate is only valid for x.com and the y.com certificate is only valid for y.com).
推荐答案
据我所知，您的所有示例都不会触发421.
None of your examples will trigger a 421 as far as I can see.
是的，您的连接正确且需要证书中的IP地址和SAN字段有效，这是正确的-没有这些连接就不应重用.
Yes you are correct that a connection needs both the IP address and the SAN field in the certificate to be valid - without those a connection should not be reused.
那么什么会触发421?据我所知，这主要是由于SSL/TLS设置不同所致.
So what would trigger a 421? As far as I can tell it will be mostly due to different SSL/TLS setups.
例如:假设网站A(siteA.example.com)和网站B(www.example.com)都位于同一IP地址上.假设网站A具有* .example.com的通配符证书，而网站B具有特定的通配符证书.可能有几个原因:例如，它为主网站提供了EV证书，而该证书不能是通配符证书.
For example: Assume website A (siteA.example.com) and website B (www.example.com) are both on same IP address. Assume website A has a wildcard cert for *.example.com and website B has a specific one. Could be a few reasons for this: for example it serves an EV cert for the main website which can't be a wildcard cert.
因此，证书A涵盖网站A和网站B.IP地址也是如此.因此，如果您连接到网站siteA.example.com，然后尝试连接到www.example.com，则从技术上讲，通过HTTP/2标准，您可以重用该连接.但是我们不想发生这种情况，因为我们想使用我们的EV证书.因此，服务器应拒绝以421.现在，在此示例中，Web服务器能够区分正确的主机并具有针对该主机的有效证书，因此，从理论上讲，可以在通配符证书下提供正确的内容，而不是发送421-但是由于未为该虚拟主机定义该通配符证书，因此不应执行此操作.
So cert A covers website A and website B. As does the IP address. So if you are connected to website siteA.example.com, and then try to connect to www.example.com then technically, by HTTP/2 standards, you could reuse the connection. But we wouldn't want that to happen, as we want to use our EV cert. So the server should reject with a 421. Now in this example the webserver is able to distinguish the correct host and has a valid cert for that host so could, in theory, serve the correct content under the wildcard cert, instead of sending a 421 - but since that wildcard cert is not defined for that virtualhost it should not do this.
其他示例包括是否在不同的主机上设置了不同的密码.例如，站点A具有超级宽松的HTTPS配置，因为它不是真正安全的内容，他们甚至希望访问旧版浏览器，但是站点B具有超级安全的配置，并且仅接受最新的TLS版本和强密码.在这里，您显然不希望他们重用相同的连接详细信息.有关此操作的真实示例，请参见此处.
Other examples include if you have different ciphers set up on different hosts. For example site A has super lax HTTPS config, because it's not really secure content and they want to reach even legacy browsers, but site B has super secure config and only accepts the latest TLS version and strong ciphers. Here you obviously wouldn't want them to reuse the same connection details. See here for a real would example of this.
这对于某些浏览器来说只是一个问题，这取决于它们决定连接共享的方式.此页面显示了每个用户执行此操作的方式有何不同(至少在撰写此博客之时不知道此后没有任何变化): https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
Also this is only an issue for certain browsers, depending on how they decide to connection share. This page shows how different each of them do this (at least at the time of this blog post not not aware of anything changing since then): https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
还要注意一些与此相关的错误(例如:https://bugs.chromium.org/p/chromium/issues/detail?id=546991 ).最好的建议是:如果您不希望发生连接共享，请使用其他IP地址和/或确保证书中没有重叠.
Also note that some bugs will exist with this (for example: https://bugs.chromium.org/p/chromium/issues/detail?id=546991). Best advice is: if you do not want connection sharing to happen, have a different IP address and/or ensure no overlaps in certificates.
这篇关于http2:421错误定向的请求状态代码示例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
