On 7 February 2017 at 22:33, Yann Ylavic <ylavic....@gmail.com> wrote: > I'm a bit reluctant with these patches, and probably need to be > convinced this isn't an application issue in the first place (why not > use X-Forwarded-Proto or alike to achieve the same? i.e. generate > https links...), or an SSL endpoint issue (why not rewrite URLs or > alike there?). It can be X-Forwarded-Proto or whatever you set it to with my patch (for the standard method of proxying). I can't speak to the ProxyProtocol one.
I also don't see what you mean by an "application issue". > > My point is that we are not changing/masquarading something which is > remote here (like the client IP address), we are making so that the > applications and httpd itself think they are locally talking SSL/TLS. > Thus they will send things like "; Secure" cookies in "clear" on the > wire, or anything which is expected to not be eavesdrop-able. The whole point of the mod_remoteip is that it tells you the request is forwarded by a trusted source, usually over an internal network, so I don't see what eavesdropping > I'd like others from the community to give their opinions here, for > now I find this quite opposite to TLS principles/expectations... It's made to work much like Apache Tomcat's RemoteIPValve. Different language, same principal. I've only used a few PHP frameworks, but whenever they require checking if the server is secure and redirecting if not, they always fall back on these three variables that are changed. HTTPS = on REQUEST_SCHEME = https SERVER_PORT = 443 (some times configurable).
