Supporting the Forwarded header (RFC 7239)

[Maxim Dounin]

Hello!

On Tue, Aug 08, 2017 at 11:52:58AM +0300, Vasiliy Faronov wrote:

> Hi Maxim,
> 
> Thank you for your reply.
> 
> 
> > I don't see how this is explicitly allowed by RFC 7239.
> 
> In Section 4:
> 
>    A proxy MAY remove all "Forwarded" header fields from a request.

Obviously enough, there are a lot of cases when proxy may want to 
remove Forwarded headers, including ones explicitly specified in 
the Section 7.2 (Header Field Preservation).

> And in Section 6.2:
> 
>    The "unknown" identifier is used when the identity of the preceding
>    entity is not known, but the proxy server still wants to signal that
>    a forwarding of the request was made.

As long as Forwarded header is not trusted, we never know if a 
forwarding of the request was mad or not.  Section 6.2 clearly 
talks about the case when we know that forwarding was made, but 
don't know the address.

> > And anyway this is an information loss, see above.
> 
> Isn't it acceptable to lose information from a badly malformed header?
> An upstream probably wouldn't be able to extract that information
> anyway, so this should only affect upstream debug/logging.

It may or may not be acceptable.  For example, this information 
can be further used to detect and/or analyze attacks, and/or 
identify requests during abuse investigation.

[...]

> > It should be more or less trivial to implement config-based
> > emulation of $proxy_add_forwarded, using map{} and appropriate
> > regular expression checks.  The main problem here is ticket #1316,
> > yet it probably should be addressed separately.
> 
> Until such a time as #1316 is dealt with, do you think it would be a
> good idea to explicitly set Forwarded to
> ngx_http_process_multi_header_lines, like X-Forwarded-For?

I don't really think that using explicit 
ngx_http_process_multi_header_lines() is a good solution, as there 
can be additional headers we don't handle explicitly.  Rather, I 
would like to try to address this in general for all unknown 
headers.

> > On the other hand, such approach also faces the problem on
> > what to do with syntactically invalid Forwarded headers, and I
> > don't think I know a solution.
> 
> Any reasonable implementation of Forwarded on the upstream must be
> prepared to deal with such malformed headers anyway. (For example,
> aiohttp is.) So, in cases where the upstream is known to do this, the
> config-based approach could be workable.

Well, config-based approach could be easily used to strip 
malformed headers.  The problem here is how to avoid information loss 
as discussed above.

-- 
Maxim Dounin
http://nginx.org/