> On Jan 7, 2017, at 3:25 PM, Reindl Harald <[email protected]> wrote:
> 
> 
> 
> Am 07.01.2017 um 22:53 schrieb Yann Ylavic:
>> On Sat, Jan 7, 2017 at 9:30 AM, Reindl Harald <[email protected]> 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


Hmmm, maybe I’m not understanding all the details, but in ATS, why not use 
header_rewrite to add whatever headers you wish to send upstream (to HTTPD)? 
That’s what I do for a particular app, which needs to know that ATS did TLS 
offloading in front of it (the app being Drupal / PHP).

— Leif

cond %{SEND_REQUEST_HDR_HOOK}
    set-header X-Forwarded-Proto https



> 
> 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

Reply via email to