> 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