Subject: HTTP/1.1 proxy behavior when Host differs from absoluteURI

From: Daniel Sommermann <[email-masked]>
Date: Tue, 11 Mar 2014 09:34:46 -0700

What is the correct behavior for a (forward) proxy that receives a 
request with an absoluteURI that differs from the Host header? 5.1.2 
suggests that the Host header should be ignored ("Note that the proxy 
MAY forward the request on to another proxy or /directly to the 
server////specified by the absoluteURI/"). 5.2 seems to suggest the 
same, but this section is scoped to the behavior of the origin server, 
not for a proxy.

If the Host header should be ignored for forwarding by the proxy, should 
the Host header be stripped or forwarded to the next hop?

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Tue, 11 Mar 2014 17:33:50 +0000

I think it's ambiguous. Squid will change the host to match that found in the URI. Our CWS proxy will simply disallow and reject the request. This is not compliant but no-one has ever complained and I don't think I see any legitimate use case for allowing this. It also smells like there could be a vulnerability to exploit in certain circumstances. Don't expect it to work well in practice.

Regards,

Richard

From: Daniel Sommermann [mailto:[email-masked]]
Sent: 11 March 2014 16:35
To: HTTP Working Group
Subject: HTTP/1.1 proxy behavior when Host differs from absoluteURI

What is the correct behavior for a (forward) proxy that receives a request with an absoluteURI that differs from the Host header? 5.1.2 suggests that the Host header should be ignored ("Note that the proxy MAY forward the request on to another proxy or directly to the server specified by the absoluteURI"). 5.2 seems to suggest the same, but this section is scoped to the behavior of the origin server, not for a proxy.

If the Host header should be ignored for forwarding by the proxy, should the Host header be stripped or forwarded to the next hop?

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 12 Mar 2014 10:50:23 +1300

On 2014-03-12 06:33, Richard Wheeldon (rwheeldo) wrote:
> I think it's ambiguous. Squid will change the host to match that found
> in the URI. Our CWS proxy will simply disallow and reject the request.
> This is not compliant but no-one has ever complained and I don't think
> I see any legitimate use case for allowing this. It also smells like
> there could be a vulnerability to exploit in certain circumstances.
> Don't expect it to work well in practice.
> 

Cache Poisoning. The security all the way to the server is predicated on 
the URL. Then the final proxy in the chain always faces the choice when 
mapping to partial-URL between retaining the Host header (poisoning the 
client response) and replacing the Host header with the value from 
absolute-URI.

It could also punt and send the absolute-URI and host header to the 
server But under section 5.1 that is the same as replacing it whenever 
the server is compliant.

While undefined there only seems to be one safe choice: replace the Host 
header.

FTR: Squid seems to have been doing its replacement since the beginning 
of HTTP/1.1 without trouble.

Amos

> MAY forward the request on to another proxy or directly to the server
> specified by the absoluteURI"). 5.2 seems to suggest the same, but
> this section is scoped to the behavior of the origin server, not for a
> proxy.
> 
> If the Host header should be ignored for forwarding by the proxy,
> should the Host header be stripped or forwarded to the next hop?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Mar 2014 20:59:10 -0700

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#page-43

Section 5.4 (Host) of p1 says:

   When a proxy receives a request with an absolute-form of request-
   target, the proxy MUST ignore the received Host header field (if any)
   and instead replace it with the host information of the request-
   target.  A proxy that forwards such a request MUST generate a new
   Host field-value based on the received request-target rather than
   forward the received Host field-value.

How on earth can that be considered ambiguous?

....Roy

On Mar 11, 2014, at 2:50 PM, Amos Jeffries wrote:

> Cache Poisoning. The security all the way to the server is predicated on the URL. Then the final proxy in the chain always faces the choice when mapping to partial-URL between retaining the Host header (poisoning the client response) and replacing the Host header with the value from absolute-URI.
> 
> It could also punt and send the absolute-URI and host header to the server But under section 5.1 that is the same as replacing it whenever the server is compliant.
> 
> While undefined there only seems to be one safe choice: replace the Host header.
> 
> FTR: Squid seems to have been doing its replacement since the beginning of HTTP/1.1 without trouble.
> 
> Amos
> 
>> Regards,
>> Richard

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Thu, 13 Mar 2014 08:48:54 +0000

It's not. Apologies. Ignore me. I was looking at the wrong doc,

Richard

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]] 
Sent: 13 March 2014 03:59
To: Amos Jeffries
Cc: [email-masked]
Subject: Re: HTTP/1.1 proxy behavior when Host differs from absoluteURI

....Roy

On Mar 11, 2014, at 2:50 PM, Amos Jeffries wrote:

>> I think it's ambiguous. Squid will change the host to match that 
>> found in the URI. Our CWS proxy will simply disallow and reject the request.
>> This is not compliant but no-one has ever complained and I don't 
>> think I see any legitimate use case for allowing this. It also smells 
>> like there could be a vulnerability to exploit in certain circumstances.
>> this section is scoped to the behavior of the origin server, not for 
>> a proxy.