2

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.

Background

The spec establishes two conditions that allow for connection reuse:

For TCP connections without TLS, this depends on the host having resolved to the same IP address.

and

For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.

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.

Specific Example In the spec

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.

Please explain where my understanding of this example is wrong:

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).

janpio
  • 10,645
  • 16
  • 64
  • 107
lf215
  • 1,185
  • 7
  • 41
  • 83

1 Answers1

5

None of your examples will trigger a 421 as far as I can see.

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.

So what would trigger a 421? As far as I can tell it will be mostly due to different SSL/TLS setups.

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.

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.

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.

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/

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.

Community
  • 1
  • 1
Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • "None of your examples..." - The example I quote in the question is not my example. It is directly quoted from the spec. My question is basically to elaborate on what the example scenario is/where my understanding of it is wrong. – lf215 Jan 22 '17 at 15:48
  • 1
    I was talking about your last section - not the quotes from the spec. That whole last section is NOT directly quoted from the spec and is not an issue as neither of the certs are valid for both x.com and y.com. – Barry Pollard Jan 22 '17 at 15:53
  • To confirm, in the middlebox example: which server is the one that sends the 421 - the middlebox proxy server or the origin server? – lf215 Jan 23 '17 at 04:58
  • 1
    Spec doesn't specify but I would think the middlebox proxy as you wouldn't want the wrong end point to get the traffic for privacy/security reasons. To me 421 means "I can't route this properly". – Barry Pollard Jan 23 '17 at 06:50