You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when set up using the AIO docker config, the CF-Connecting-IP and X-Forwarded-For headers are removed by both nginx [1] and Caddy [2] (I was unable to to determine if this is done for Kubernetes as well) for requests it sends to piped-proxy. However, this protection is incomplete:
There is a list of additional CF-* headers as well as X-Forwarded-Proto, True-Client-IP and CDN-Loop in Cloudflare's documentation [3] that can identify the request as not coming directly from a client device.
The default behavior for both Caddy [4] and nginx [5] is for all headers to be passed when proxying the request, with some exceptions, and the AIO docker config does not turn these off. (I am not familiar with Kubernetes so I can't tell if the provided config is doing the same)
Caddy itself will set X-Forwarded-Proto and X-Forwarded-Host along with X-Forwarded-For when it proxies the request [4] unless those headers are manually removed.
It doesn't appear like any configs are doing this currently, but the Forwarded header will contain the same information as the X-Forwarded-* ones if it is added by whatever load balancer/reverse proxy is in use.
Based on this, I'm thinking if it might be better to strip these headers in piped-proxy instead of relying on the Docker AIO config or custom load balancer solution to do it.
The current list at the time of this writing seems to be:
Currently, when set up using the AIO docker config, the
CF-Connecting-IP
andX-Forwarded-For
headers are removed by both nginx [1] and Caddy [2] (I was unable to to determine if this is done for Kubernetes as well) for requests it sends to piped-proxy. However, this protection is incomplete:CF-*
headers as well asX-Forwarded-Proto
,True-Client-IP
andCDN-Loop
in Cloudflare's documentation [3] that can identify the request as not coming directly from a client device.X-Forwarded-Proto
andX-Forwarded-Host
along withX-Forwarded-For
when it proxies the request [4] unless those headers are manually removed.Forwarded
header will contain the same information as theX-Forwarded-*
ones if it is added by whatever load balancer/reverse proxy is in use.Based on this, I'm thinking if it might be better to strip these headers in piped-proxy instead of relying on the Docker AIO config or custom load balancer solution to do it.
The current list at the time of this writing seems to be:
CF-Connecting-IP
CF-Connecting-IPv6
CF-EW-Via
CF-Pseudo-IPv4
True-Client-IP
CF-RAY
CF-IPCountry
CF-Visitor
CDN-Loop
CF-Worker
X-Forwarded-For
X-Forwarded-Proto
X-Forwarded-Host
[1] https://github.com/TeamPiped/Piped-Docker/blob/main/template/ytproxy.conf#L3
[2] https://github.com/TeamPiped/Piped-Docker/blob/main/template/Caddyfile#L41
[3] https://developers.cloudflare.com/fundamentals/reference/http-request-headers/
[4] https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults
[5] https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_request_headers and note the default setting is
on
The text was updated successfully, but these errors were encountered: