On Tue, Feb 7, 2017 at 10:14 PM, Jordan Gigov <colad...@gmail.com> wrote: > 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".
I mean the application can know about "X-Forwarded-Proto or whatever" header, it could act with it like it does with HTTPS=on (if it wishes). > >> >> 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 It tells you what remote information of the request is trustable, which is not the same (IMHO) as a local information like _this_ server (running the application) is using https. > >> 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). That's what I called an application issue, I don't see why PHP wouldn't trust other variables if PHP users want to, or the application/script force those (or whatever) for _PHP_ to act as if, or the act as if directly... Why would the server lie? I'd be fine with the server setting REMOTE_HTTPS=on and/or REMOTE_SCHEME=https, though.
