Look at X-Forwarded-Proto for the HTTPS environment variable

[mpdude]

Amazons ELB don't use X-HTTPS but instead set an "X-Forwarded-Proto: https" header when forwarding https connections.

It would be great if that header (and its value) could be considered alternatively to X-HTTPS.

[mpdude]

Seems this also gets the SCRIPT_URI variable right that mod_rewrite adds. Without this, you might end up with "http://...:443/..." URLs - that is, the X-Forwarded-Port is honored but added explicitely because it differs from the default for the assumed scheme.

[gberche-orange]

I understand that with this patch, both X-HTTPS and X-Forwarded-Proto headers are used to detect HTTPS protocol by the upstream reverse proxy.

For load balancers that only define X-Forwarded-Proto and not X-HTTPS, this opens a security breach in that a malicous client might generate an HTTP request with a additional "X-HTTPS" header to fool the origin server into thinking it was contacted over HTTPS.

Would it make sense to add a new RPAF_Proto_Header configuration directive that specifies the expected HTTP header used to transport the protocol of the request as seen by the reverse proxy ? Default value might be X-HTTPS if backward compatibility needs to be present.

A sample conf could then look as:

LoadModule        rpaf_module modules/mod_rpaf.so
RPAF_Enable       On
RPAF_ProxyIPs     127.0.0.1 10.0.0.10 10.0.0.20
RPAF_SetHostName  On
RPAF_SetHTTPS     On
RPAF_Proto_Header  X-FORWARDED-PROTO
RPAF_SetPort      On

[gnif]

Good point, I will see about patching this in, it is indeed a possible security issue.

[mpdude]

@gberche-orange I think your above point is still valid, isn't it? You think you could craft a PR for that?

[gberche-orange]

@mpdude

Sorry, I was suggesting use of mod_rpaf into the php-buildpack, but they choosed to implement the x-forwarded-* differently not using mod_rpaf. I won't be able to contribute a PR on mod_rpaf.

[mpdude]

Ok, thanks for your reply!