Re: Host and :authority (was Re: Working Group Last Call: HTTP/2 revision)

> Am 06.09.2021 um 18:47 schrieb Willy Tarreau <w@1wt.eu>:
> 
> On Mon, Sep 06, 2021 at 03:20:54PM +1000, Martin Thomson wrote:
>> In effect, RFC 7540 says:
>> 
>> 1. If :authority is present, servers must use :authority and ignore Host.
>> 2. Servers use Host if :authority is absent.
>> 3. Intermediaries must preserve Host when forwarding requests.
>> 4. Clients are encouraged to generate requests with :authority, but can use Host if they choose.
>> 
>> Roy's theory about h2->h1->h2 being the reason for (3) is correct, at least
>> as far as I can remember (something I've confirmed with others who were
>> there).
> 
> I agree with this, but this doesn't require that the contents of an invalid
> Host are preserved, just that the field's presence is preserved.
> 
>> My *opinion* is that this is a poor design for a few reasons, but
>> mostly because Host and :authority can disagree.
> 
> But the problem in the first place is: "why and when could Host and authority
> disagree" ? There's a MUST in the specs regarding their equality when producing
> them. I don't know if you've seen my other message in this mail where I
> enumerated the different combinations, I think it's a good start to verify
> how we could end up with this problem in the first place.
> 
>> Is this really so bad that it needs to be fixed?
> 
> It's trivially exploitable, especially in dual-stack servers and/or
> intermediaries. At some point the admin must configure a rule to decide
> what to serve. Usually it's host-based (by heritage from H1 which almost
> did not use authority in servers). When two agents along the chain use a
> different one to route the request, some requests get misrouted to the
> wrong server, and this can have really bad effects, such as permitting
> access to private resources that were expected to be blocked at the edge.
> 
>> I've seen a few amendments suggested in this thread (and others):
>> 
>> a. We might make :authority mandatory in more cases.
>> b. We might prohibit inclusion of both values.
>> c. We might prohibit different values if the fields are both present.
>> d. We might avoid levying requirements on intermediaries that forward requests.
>> 
>> We are limited in what we can do here because we can't require anything that
>> might result in an unmodified RFC 7540 implementation producing fatal errors.
>> For instance, we might insist that clients not include both fields, but we
>> can't require servers to enforce that.  That limits the value of any change.
> 
> I think that the least impacting one would be C. We still failed to enumerate
> a single valid case for mismatching host and authority and this is the basis
> of the problem. If we decide that when set and non-empty both must match,
> in my opinion the problem is solved.
> 
>> The best option I've seen for any change is to remove the bit where we
>> mandate that Host is preserved when forwarding.  We might further recommend
>> against including Host in favour of :authority.  That's in direct
>> contradiction to decisions in RFC 7540, but I think we have some support for
>> the notion that we made a mistake in mandating that Host be preserved.
>> 
>> Doing nothing is also OK.  It is a invalid to route on Host when :authority
>> exists; that some implementations might do that is not something we are
>> obligated to fix in the specification.
> 
> It's particularly dangerous once converted to HTTP/1, because there you're
> certain that Host will be used and not all implementations will check that
> the authority matches it.
> 
>> This sort of issue is exactly the sort of thing that our initial scoping
>> exercise was designed to avoid.  There are lots of decisions in RFC 7540 that
>> we might second guess; we deliberately chose not to redo all of them.  And
>> yet here we are.
> 
> I know, but if there are bugs that are causing vulnerabilities in field,
> we should address them.
> 
> Maybe the very least we could do is to add:
> 
>   An implementation which detects that Host and :authority do not match
>   MAY reject the request as malformed.
> 
> We don't take risks and I'm sure most of us will instantly enforce this.
> I'd personally prefer a SHOULD or even a MUST (to match what is inferred
> by the two rules in H1 that state that they must be produced identical
> and that non-conformant ones must be dropped) but at least with this we
> can all plug this hole.
> 
>> p.s., the editor's draft contains a revision to the text in question, that I
>> think greatly improves its clarity; see
>> https://httpwg.org/http2-spec/draft-ietf-httpbis-http2bis.html#section-8.3.1-2.3.1
> 
> Sure, I definitely agree, it's just that the "must retain" rule maintains
> the ambiguity regarding non-matching values.

Current Apache httpd h2 implementation:
- if :authority: is given, it overrides host: before internal processing starts
- if :authority: is missing, host: is used instead
- if both are missing, request is rejected

Proposal C would mean we check before overwrite and fail if a 'different' value is present. We then need to define 'different'. It seems quite common in the h1 world to be forgiving on port numbers, afaik. And how we match names...

After living for 5 years with the current implementation, I am not sure I'd like to change it.

- Stefan

Received on Tuesday, 7 September 2021 08:19:54 UTC