Subject: #550 handling mismatches between socket connection and host header field

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jan 2014 22:53:30 +0100

During IESG review, Ted Lemon came up with this interesting DISCUSS 
(<http://tools.ietf.org/wg/httpbis/trac/ticket/550>):

> In (Part 1 Section) 5.5, suppose I connect to foo.example.org on port 80, and send the following:
>
>   GET / HTTP/1.1
>   Host: foo.example.org:8080
>
> This produces an effective URI of ​http://foo.example.org:8080/. What is the server supposed to do at this point? The obvious way to resolve this DISCUSS point is to update the text to address this problem. I think this example has the same property that leads you to require a 301 or 400 status in section 3.1.1.

I (telnet-)tested this with various servers, and they don't seem to 
bother checking the port number.

So we could clarify that this request is invalid, but I'm not sure we 
can add a normative requirement to fail the request.

Feedback appreciated!

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 16 Jan 2014 23:00:48 +0100

>can add a normative requirement to fail the request.

It seems it would also be possible to say the actual port connected to
takes precedence (where applicable). Would that cause any problems?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jan 2014 23:14:07 +0100

> takes precedence (where applicable). Would that cause any problems?

"takes precedence" implies that the port portion of the host header 
field value always is ignored, right? Not sure whether we want to say that.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 17 Jan 2014 12:06:03 +1300

> field value always is ignored, right? Not sure whether we want to say

This sort of falls into the previous discussion about CVE-2009-0801 
where the Host domain/raw-IP content does not resolve to the IP address 
of the underlying connection. We have identified quite a bit of bad 
behaving services with this in Squid.

It is only relevant to middleware relaying the request elsewhere. Origin 
servers have other means to determine whether the header is used or 
needs validating validated.

The current behaviour we use in Squid with a lot of success is to open 
the outgoing connection to the same IP:port the client TCP connection 
used and otherwise treat the request as if it arrived with absolute-URL 
containing the raw-IP:port. This has the side effect of causing the Host 
header to be converted to raw-IP:port details on outgoing but this has 
rarely led to trouble, and more often leads to upstream proxies 
contacting the "right" server despite being vulnerable themselves, so 
has been well worth it.

We have had to take unreasonable care NOT to validate received Host 
header on messages containing absolute-URL. An unfortunately large 
amount of regular proxy traffic contains mismatches. However it is also 
worth noting that for several decades at least Squid has been 
unconditionally replacing the Host header with the absolute-URL 
host:port details with no known complaints.

Amos