Re: X-Forwarded-For and HTTP2

On 8/07/2015 8:28 p.m., Fedor Indutny wrote:
> Hello again!
> 
> I have a question/suggestion with regards to HTTP2 spec, and TLS
> terminator implementations.
> 
> 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.
> 
> One of the ways is to add `x-forwarded-for` header for every
> request, but it requires parsing the underlying protocol (be it
> HTTP2, SPDY, or HTTP/1.1), which is rather costly.
> 
> Another approach is to send (so called) proxyline. This is what
> [HAProxy][0], and stud ([hitch][1]) are doing at the moment.

FWIW, Squid now also support this.

> In
> a few words this means prefixing all decrypted data with a single
> line specifying the client's IP address and port (and sometimes
> more metadata, like TLS servername and other protocol-specific
> things).
> 
> And the third approach that is to the best of my knowledge is
> implemented only in [bud][2] TLS terminator - is to add special
> SPDY frame, asking the SPDY server to automatically add
> `x-forwarded-for` for every incoming connection.
> 

XFF header is now deprecated. Forwarded (RFC ) was standardized in its
place.

> What I was wondering if this frame could be standardized, or at
> least if it might be possible to allocate the frame type for it.
> So that people may use it for their own purposes, without being
> afraid of the possible frame type conflicts.
> 
> What are your thoughts on this?
> 

Software properly supporting the X-Forwarder-For, Forwarded and/or Via
headers will send them appropriately without being told to. Any
difference from that is an explicit sysadmin policy on the senders side.

The security model behind XFF and Forwarded is that the message *sender*
uses it to indicate the level of responsibility it is willing to take on
for the message. Naming itself as the responsible party, or pointing at
some other source which may or may not be anonymized in turn.

The recipient of messages has no place imposing requirements on the
senders internal security policy. It can only determine its own level of
trust for the information provided, if and when its provided.

Amos

Received on Wednesday, 8 July 2015 10:52:10 UTC