Re: Benjamin Kaduk's Discuss on draft-ietf-httpbis-messaging-16: (with DISCUSS and COMMENT)

Hi Mark,

On Fri, Jul 02, 2021 at 06:09:16PM +1000, Mark Nottingham wrote:
> Hi Ben,
> 
> > On 19 Jun 2021, at 11:17 am, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > 
> > My complaint was
> > attempting to focus specifically on the procedure for converting the
> > request-target to the target URI, since in this one specific case of the
> > absolute-form request target the procedure is that "the target URI is
> > defined to have the same value as the request-target" and there seem to be
> > some edge cases relating to the scheme selection.
> > 
> > At a high level, my point is that if a client sends a request with
> > request-target of https://www.example.com over TCP-without-TLS, I expect
> > the client to get back an HTTP 4xx response over that TCP channel, or maybe
> > just a TCP RST.  In particular, I do not expect it to get a non-4xx
> > response, and definitely not 200 with content from the "https" origin.
> > There are actually quite a few places in the flow of processing the message
> > where this could be done, across both -messaging and -semantics, but I
> > don't remember a specific place that gives a clear direction to the server
> > implementation to handle this scenario.
> 
> The server reconstructs the target URI and identifies the associated resource, as per 7.1. If the scheme is HTTPS but the transport is not TLS, that resource won't be found (at least in HTTP/1.1), so you'll get a 4xx, probably a 421 on a modern server. Some quick testing with Apache gives a 301 back to the same URI, which also works (I suppose).

That's reassuring to hear (and the 421 is intuitive, while 301 also makes
some kind of sense now that it's pointed out).  I'm not entirely sure where
the requirement for "if the scheme is HTTPS but the transport is not TLS"
comes from, though.  But perhaps I should keep reading in this mail...

> 
> >> Martin commented:
> >> 
> >>> I think that this question doesn't really read on -messaging, but more 
> >>> on -semantics.  However, I am not seeing any requirement on the server 
> >>> to ensure that the response it generates is secured.
> >>> 
> >>> s 4.2.2 of semantics -- 
> >>> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.uri
> >>> 
> >>>> A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts secured responses to those requests. Note that the definition of what cryptographic mechanisms are acceptable to client and server are usually negotiated and can change over time.
> >>> 
> >>> No similar requirement is made of the server.  It would be trivial to 
> >>> impose a similar requirement on servers in that same paragraph.
> >> 
> >> I don't think that helps, at least in the case of HTTP/1.1. There, the server is responsible for setting the correct scheme for the target URI when a request is received; the security properties of the request and response follow from that. Effectively, it's not under attacker control.
> > 
> > (This is the part where I'm most confused.)
> > Where is the requirement specified that the server set the correct scheme
> > for the target URI?  If the procedure to set the taret URI is "use the
> > scheme the client gave you", that seems like it's clearly under attacker
> > control, so I don't understand how you reached the conclusion in the final
> > sentence.  Were you maybe talking about h2 at that point and not HTTP/1.1?
> 
> Aha - I see what's happened. 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.

Yes, exactly, that's what stuck out at me.  Sorry for not quoting it more
explicitly from the start.

> 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.
> 
> Does that make sense to everyone (especially Roy, who has the most history here)?

That makes perfect sense to me, but I expect that we should make strenuous
efforts to hear from others who have more knowledge of the history before
proceeding with it.

Thanks,

Ben

> >> However, I don't see any equivalent mechanism regarding :scheme in http/2 bis  or http/3. Off the cuff, I tend to think that security considerations about this probably belong on both of those specs.
> > 
> > That makes sense to me, as does spinning it off to a separate issue for
> > h2-bis.  I will note that I didn't raise a concern for h3 and :scheme
> > processing since h3 always requires secure transport and the failure
> > case didn't seem very significant.
> 
> See https://github.com/httpwg/http2-spec/issues/867
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
>

Received on Wednesday, 7 July 2021 00:46:29 UTC