On Sat, Jan 7, 2017 at 2:30 AM, Reindl Harald <h.rei...@thelounge.net> wrote: > * Apache Trafficserver in front > * ATS configured for TLS-offloading > * connection to backend-httpd on the LAN unencrypted > * mod_remoteip correctly configured on backend httpd > > is there any way to make the backend php application aware that in fact > $_SERVER['HTTPS'] and $_SERVER['REQUEST_SCHEME'] should be 'on' / https:// > in case of generate absolute URLs like for emails > > in a perfect world this would be handeled like the transparent translation > of the client IP with > https://httpd.apache.org/docs/current/mod/mod_remoteip.html and it's > RemoteIPInternalProxy and a header like "X-Forwarded-TLS" > > something like below where "X-TLS-Offloading" is only evaluated from > "RemoteIPInternalProxy" pyhsical addressess > > RemoteIPHeader X-Forwarded-For > RemoteTLSHeader X-TLS-Offloading > RemoteIPInternalProxy 192.168.196.1
The presence of TLS is a rather strict contract, in this example it doesn't exist end-to-end, so there is a wire segment that is sniffable (and yes you can also argue that a physical box, given access, is sniffable). This particular example would require all RemoteIPInternalProxy gateways to correctly de-taint any previous X-TLS-Offloading value. In other words, many ways to get this wrong in a day where end-to-end encryption is required by many policies. I'm hesitant to introduce this into mod_remoteip... the configuration of absolute URL's in text/html output would probably follow the same setup as any other situation where the app server is not physically on the wire, but hiding behind a gateway. mod_proxy_html or mod_sed in httpd easily handle this for apps that can't be reconfigured, I'd presume ATS offers a similar feature. You can float this as a patch to mod_remoteip in bugzilla. It might not be accepted, but that would be a place for interested users to find such an example hack and perhaps adopt it.
