Hello!

On Sat, Jan 16, 2021 at 07:38:49PM +0300, Murad Mamedov wrote:

> First of all, ignore patch in first mail, I don't use mercurial on
> daily basis, and my neomutt screwed the patch. Second mail in thread
> contains just patch and it seems to be correct.
>
> I wanted to address few other things on the subject. I started my way
> from
> http://mailman.nginx.org/pipermail/nginx-devel/2016-November/009083.html,
> however decisions done there I found incorrect. Author tried to jump
> right into XCLIENT from PROXY PROTOCOL. In proposed implementation proxy
> protocol is handled in the begining of connections. Since XCLIENT gets
> its address from ngx_connection_s, it will get automatically downstream
> provided address of client.
>
> In the same thread, there was questions on how to deal with
> "real_ip_header" and "set_real_ip_from". As I mentioned in the original
> description to the patch, one may need these in case of HTTP protocol,
> which is very flexible, with tons of applications behind that may demand
> presense of real ip address in different places/headers. For ancient mail
> protocols, it is not the case. They are very strict, very few
> applications that implement it, probably Postfix, Exim and Dovecot be
> the only practical implementations. And they do support proxy protocol
> out of the box. So I could not find real reason to apply "real_ip"
> thing. With proposed implementation, it just worked out of the box, with
> minimum configuration. The only thing which could be added if need is
> the overriding of "destination address" of proxy protocol (i.e. address
> which client reached). For now I didn't see where it could be useful in
> mentioned above mail applications. Client address, yes, we do pass,
> server address ¯\_(ツ)_/¯, who cares.

The main problem the "real_ip thing" is expected to address is
that whithout set_real_ip_from restricted set of addresses to
accept IP address from you are open to IP spoofing.

Most recent relevant discussion about "why one should never trust
X-Forwarded-For addresses and what to do with the fact that many
don't understand it" can be found in the thread here:

http://mailman.nginx.org/pipermail/nginx/2021-January/060319.html

Mail proxying is indeed much simplier than http, yet the question
is still here: how to ensure that "listen ... proxy_protocol;" is
only configured to accept client IP addresses from trusted
sources.

Blindly assuming that anyone who used "listen ... proxy_protocol;"
in the configuration took care and restricted access to the
listening socket in question on the network level might not be a
good idea. Especially given it works differently in both http and
stream modules. Rather, I would like to see it equivalent to how
it is implemented in the stream module with "set_real_ip_from"
(http://nginx.org/en/docs/stream/ngx_stream_realip_module.html).

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel