Ben Kaduk's DISCUSS on Semantics - absolute URIs as request targets

[mnot]

From @kaduk -

Let's discuss whether the currently specified procedures for reconstructing the target URI from a request-target in absolute-form provide adequate security properties, at the origin server. I'm specifically concerned about taking the scheme directly from the request target, i.e., making the distinction between the "http" and "https" schemes. The simple procedure of "take the scheme from the request-target" would seem to allow for the client to cause the server to engage processing for the "https" origin without receiving the protection that https is supposed to provide. (The converse case does not immediately seem to present much risk but is probably worth preventing as well on general principles of retaining consistency.) I don't remember seeing any text that would require the server to validate the scheme from the request-target against the actual properties of the transport (or the configured fixed URI scheme as might be provisioned with a trusted outbound gateway, etc.) While we do reference §7.4 of [Semantics] with a note that reconstructing the target URI is only part of the process of identifying a target resource, that part of [Semantics] does not mention scheme validation as part of rejecting misdirected requests.

Does the origin server need to validate the scheme from an absolute-form request-target? What is the scope of consequences if it fails to do so?

[mnot]

I said:

In 3.3 of 1.1 https://httpwg.org/http-core/draft-ietf-httpbis-messaging-latest.html#reconstructing.target.uri I was skimming by the initial text:

The target URI is the request-target when the request-target is in absolute-form.

... whereas you obviously picked up on it. I agree that there's an issue here.

The decisions about absolute-form requests were made way back when. My reading of the archive (circa September and October 1995 -- I'm sure those that were there will correct me) is that Host headers were added to address the multiple-hosts-on-an-IP problem in a way that was backwards-compatible with HTTP/1.0, but because some folks wanted to enable the use of URNs, proxies were required to support and use the absolute form, so that URNs could be (theoretically) resolvable through them. That didn't happen, but it is possible to use e.g., FTP through a HTTP proxy as a result (last I looked).

I think the solution here is to restrict the statement above so that it only applies to proxies, and to add a requirement for origin servers (including gateways) to specifically check absolute-form URIs for alignment regarding the scheme.

[MikeBishop]

It seems to me that the ability to do cross-protocol requests is a deliberate feature of HTTP, and not one we should interfere with now, even if it's rarely used. In fact, RFC 8164 explicitly relies on the ability to request "http" resources over an "https" connection.

I agree that servers should not respond to requests that assume a secure channel over an insecure one. While Sections 4.2.2 and 4.3.3 seem to put most of the burden on the client not to make such requests, the server should probably consider such a request misdirected even if it is authoritative.

Perhaps the least disruptive solution would be text in 7.4 adding https:// URIs received over insecure connections as another instance of a potentially misdirected request?

[royfielding]

Let's discuss whether the currently specified procedures for reconstructing the target URI from a request-target in absolute-form provide adequate security properties, at the origin server.

Before I get into the text, I need to clarify that this question is misplaced. The procedure for reconstructing the target URI is about reconstructing what the client sent. It is not about security (yet). It has nothing to do with ensuring the connection is secure. It is about understanding the request as received.

AFTER the request is understood, the server needs to determine whether it can answer the request in that context. How it determines that is an internal configuration issue, not a protocol standard (because HTTP requests can arrive via any underlying transport), but there are things we can add to make the process clearer without assuming that all HTTP requests are made by general-purpose browsers.