Am 07.01.2017 um 22:53 schrieb Yann Ylavic:
On Sat, Jan 7, 2017 at 9:30 AM, Reindl Harald <h.rei...@thelounge.net> wrote:
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
Wouldn't something like this work?
RewriteRule on
RewriteCond %{ENV:remoteip-proxy-ip-list} .
RewriteCond %{HTTP:X-TLS-Offloading} ^true$
RewriteRule ^ - [E=HTTPS:on,E=REQUEST_SCHEME:https]
Given that remoteip-proxy-ip-list is filled by mod_remoteip if (and
only if) RemoteIPInternalProxy matches
currently not because nothing provides "X-TLS-Offloading" which is the
reason for add both parties to this conversation
such global rewrite rules are not very appealing while the intention of
get this handeled by mod_remoteip is that for the admin this would be
the central place to deal with backendsservers with a proxy in front
it is handeled perfectly for the REMOTE_ADDR where for every access(deny
rules, loggings, mod_security-rules and within applications you can
trust it's the clients IP and not one from own infrastructure
end-to-end-encryption (one argunmet which came against it) is something
one needs to consider anyways if TLS-offloading come into the mix and
the connection between proxy and backend needs to be 100% trusted, but
it's a great way to spread load of generate dynamic content and
encryption to different machines and should be 100% transparent to the
application
generate links for emails and secure-flag for cookies are the first
things coming to my mind but likely not all hidden cases where missing
awarness the the client connection is encrypted may lead to undesired
behavior