Re: X-Forwarded-For and HTTP2

--------
In message <CAEv2VfJyOnQ9Ft7t92GSH6HTVuEYOoz_6R_axuUHF3TrViP-mw@mail.gmail.com>, Fedor Indutny writes:

>When HTTP2 (or previously SPDY) is used under the TLS terminator,
>there is a big question about how the address of the original
>client should be sent to the back end.

I think we should actively discourage this practice going forward.

Lets turn the question around:

Why is it people think they need the network address in the first place ?

About the only thing X-F-F style data can tell you is *roughly*
where in the world the HTTP Proxy, NAT gateway or TOR exit-node
filtered the HTTP client onto the "open" network.

Very often it is badly misleading.

This can be for benign reasons, see for instance Opera story about
how "virtual norvegians" were the most common visitors to a US (fire
brigade ?) web-page.  (Didn't save the link, sorry.)

Or it can be for hostile reasons, such as people trying to bypass
restriction mechanisms on A/V content or sneak through ill-advised
ACLs.

(Strictly speaking people have only themselves to blame if they trust
X-F-F headers from untrustworthy proxies or clients, but that fine
print seems to be universally not be in HOWTOs and I fear the
practice is much more widespread than is good for anybody.)


On the plus side: The network address has *some* value as debugging
aid, but the frequency of that happening, makes it a very weak
argument for the overhead of managing/communicating the NA's.


If we decide that NA's are useful enough that they should be provided
down-stream, they need to be per-request, that follows directly
from the HTTP specs: proxies are allowed to mux.

If we provide NA's they almost certainly would have to be in
text-string format, because as far as I know, there is no universally
agreed binary representation format for IPv4/TCP and IPv6/TCP
addresses (whereas we have *far* too may textual represenations
to handle).

There *is* the on-wire format in the actual TCP/IP packet address
fields, but that is not supported by the sockaddr based APIs, so
that would be a pretty bad choice.


In other words: it's X-F-F or nothing, and nothing would be the
wiser choice for the long term.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 8 July 2015 20:53:43 UTC