- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 23 Apr 2013 08:55:25 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Tue, Apr 23, 2013 at 04:17:22PM +1000, Mark Nottingham wrote: > > On 23/04/2013, at 4:15 PM, Willy Tarreau <w@1wt.eu> wrote: > > > On Tue, Apr 23, 2013 at 04:02:22PM +1000, Mark Nottingham wrote: > >> Just wondering if we need to explicitly point out the security considerations > >> around the following: > >> > >> * Message routing -- it's somewhat common AIUI for intermediaries to only > >> route on the Host header, for performance reasons; i.e., they do not > >> reconstruct the effective request URI (as required by p1 5.5). I know there's > >> a theoretical risk here, but is there a real-world risk that we should point > >> out? > > > > I see no particular risk since the Host header field is mandatory. Also in > > practice, intermediaries which "route" requests tend to be very close to > > the servers, at places where the security considerations are very specific > > to the environment and explicitly covered in this intermediary's configuration. > > That's what I was wondering. What concerned me was that people deploy load > balancers in front of proxies, and virus scanners, etc. I don't have a > specific attack in mind, it just feels like there probably is one. At least in my experience, when deploying a load balancer in front of a proxy farm or anti-virus farm, parts of the URI are used more than the Host header field. For example, you can have an LB which decides that requests for file ending in ".mpg" do not pass through the virus scanner and go directly to the proxy, but in return the content-type must absolutely match "video/mpeg" otherwise they're blocked (it's just an example). That's why I think that the security considerations are much more of a global thing in such deployments than just a matter of correctly relying on the Host header field. Willy
Received on Tuesday, 23 April 2013 06:58:25 UTC