Bug report for Apache httpd-2 [2017/01/08]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity|
| 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to|
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11294|New|Enh|2002-07-30|desired vhost_alias option|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst|
|14922|Inf|Enh|2002-11-28| is currently hardcoded to 'apache2'  |
|15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne|
|16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config  |
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17107|New|Min|2003-02-16|Windows should not install printenv   |
|17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|18325|New|Enh|2003-03-25|PAM support for suEXEC|
|18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L|
|19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util|
|23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an|
|23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl|
|23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s|
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25014|New|Enh|2003-11-26|A flexible interface for mod_log_config   |
|25201|New|Enh|2003-12-04|Provide Cache Purge operation |
|25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information|
|25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|25543|Inf|Nor|2003-12-15|mod_proxy_ajp overwrites existing response headers|
|25667|New|Nor|2003-12-19|Memory leak in function ssl_scache_dbm_retrieve().|
|25863|New|Enh|2004-01-02|new per-host initialization hooks |
|26005|New|Nor|2004-01-08|SERVER_NAME incorrect when using IPv6 address in U|
|26142|New|Maj|2004-01-14|EnableSendFile Off for Windows XP Home|
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|26368|New|Min|2004-01-23|File extensions in AddDescription treated as part |
|26446|New|Nor|2004-01-26|flush buckets followed by eos bucket emit multiple|
|26478|New|Enh|2004-01-28|mod_dav does not expose a method for setting the D|

Re: clang-analyzer?

[William A Rowe Jr]

Several times a year, we get offers or full dumps of programmatic static
code analysis.

We have, for decades, rejected it all, and invited reporters to bring
specific analysis of actually problematic cases back to the list (or
security@, as applicable.)

If anyone is interested, we consistently invite reports of actual defects
or security issues to be resolved.

Cheers,

Bill

On Jan 7, 2017 8:45 PM, "Leif Hedstrom"  wrote:

> Howdy,
>
> I ran clang-analyzer against the HTTPD master branch, and it found 126
> issues. Many of these are benign, but I was curious if the community has
> any thoughts on this? With another project, I’ve found that keep static
> code analysis to zero issues can really help finding new, serious issues
> (basically, we put the tree in failed state if there’s a new static code
> analysis issue).
>
> The issues are all over the source code, in core and mod_’s alike. It’d be
> pretty tedious to file individual tickets for each of them, so curious if
> there’s any interest in cleaning this up to start with a clean state? It’d
> then be easy to add clang-analyzer to the release process for example.
>
> Thoughts?
>
> — leif
>
>

Re: httpd-2.2.x and C89... ;-(

[NormW]

G/A and apologies for the delay...I'm not on the net 24/7...
Yes, a 'clean' and 2.2.x build goes to completion without issue.
Norm

On 8/01/2017 12:29 AM, Yann Ylavic wrote:

On Sat, Jan 7, 2017 at 1:35 AM, William A Rowe Jr  wrote:

Great catch, thanks Norm. That too is part of the r1753592 backport
proposal, hoping someone is willing to look at these proposals.


Now backported to 2.2.x (r175), along with other accepted "SNI" patches.
Norm, does it work for you?

On Sat, Jan 7, 2017 at 12:20 PM, Jan Ehrhardt  wrote:

NormW in gmane.comp.apache.devel (Sat, 7 Jan 2017 11:31:32 +1100):

D:\Projects\svn\httpd-2.2.x>svn diff
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c   (revision 1777591)
+++ modules/proxy/mod_proxy.c   (working copy)
@@ -1088,9 +1088,9 @@
   * backend itself but by the proxy e.g. a bad gateway) in order to 
give
   * ap_proxy_post_request a chance to act correctly on the status code.
   */
+int post_status = proxy_run_post_request(worker, balancer, r, conf);
  saved_status = r->status;
  r->status = access_status;
-int post_status = proxy_run_post_request(worker, balancer, r, conf);
  /*
   * Only restore r->status if it has not been changed by
   * ap_proxy_post_request as we assume that this change was 
intentional.


r (or rather r->status) is changed in between the added line and the
deleted line, so it seems better to do it like this:


Right, though r175 combined another change which avoided the
warning altogether.

Thanks anyway Norm/Jan for testing/review.

Regards,
Yann.

clang-analyzer?

[Leif Hedstrom]

Howdy,

I ran clang-analyzer against the HTTPD master branch, and it found 126 issues. 
Many of these are benign, but I was curious if the community has any thoughts 
on this? With another project, I’ve found that keep static code analysis to 
zero issues can really help finding new, serious issues (basically, we put the 
tree in failed state if there’s a new static code analysis issue).

The issues are all over the source code, in core and mod_’s alike. It’d be 
pretty tedious to file individual tickets for each of them, so curious if 
there’s any interest in cleaning this up to start with a clean state? It’d then 
be easy to add clang-analyzer to the release process for example.

Thoughts?

— leif

Re: how make backend applications aware about tls-offloading

[Leif Hedstrom]

> On Jan 7, 2017, at 3:25 PM, Reindl Harald  wrote:
> 
> 
> 
> Am 07.01.2017 um 22:53 schrieb Yann Ylavic:
>> On Sat, Jan 7, 2017 at 9:30 AM, Reindl Harald  wrote:
>>> 
>>> something like below where "X-TLS-Offloading" is only evaluated from
>>> "RemoteIPInternalProxy" pyhsical addressess
>>> 
>>> RemoteIPHeader X-Forwarded-For
>>> RemoteTLSHeaderX-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

Re: how make backend applications aware about tls-offloading

[Yann Ylavic]

On Sun, Jan 8, 2017 at 12:39 AM, Reindl Harald  wrote:
>
> Am 08.01.2017 um 00:31 schrieb Yann Ylavic:
>>
>> On Sun, Jan 8, 2017 at 12:22 AM, Reindl Harald 
>> wrote:
>>>
>>>
>>> ok, so we need to continue the code below and set the option in every
>>> tls-offloaded application - intention of this thread was maybe get this
>>> transparent which seems not to be possible
>>
>>
>> It is "technically" possible, but not wise IMHO.
>> Making every httpd module/CGI/app think the local connection is https
>> could lead to things like "; Secure" cookies sent on the (clear) wire,
>> and that option would be accompanied with so much warnings ("unless
>> you're really on the same switch, but even that...") that it'd be hard
>> to defend (endlessly?).
>
> excatly *that* would be the desired result if configured that way because
> the "clear wire" is controlled and trusted in that context and you *want*
> the secure flag sent for cookies between the tls-offloading server and the
> enduser to not get them back unencrypted over the "real clear wire"

I'm pretty sure the RFC does not allow for "secure" cookies to go in
clear, but that'd be an admin choice after all.
An RFC (as-much-as-it-can-)compliant server can hardly feature it, though.

>
> the whole purpose of *tls offloading* is run the application on a virtual
> machine with a preforked httpd and encryption on the reverse-proxy running
> multithreaded with keep-alive
>
> another secuity gain here is that the amchine which runs application code
> never has a change to see the private ssl key while a breach on the proxy
> with no application code is less likely

That's your architecture choice (constraint?), but you could achieve
the same by proxying to php-fpm for example, and possibly have more
response rewrite/reverse options too...

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 08.01.2017 um 00:31 schrieb Yann Ylavic:

On Sun, Jan 8, 2017 at 12:22 AM, Reindl Harald  wrote:


ok, so we need to continue the code below and set the option in every
tls-offloaded application - intention of this thread was maybe get this
transparent which seems not to be possible


It is "technically" possible, but not wise IMHO.
Making every httpd module/CGI/app think the local connection is https
could lead to things like "; Secure" cookies sent on the (clear) wire,
and that option would be accompanied with so much warnings ("unless
you're really on the same switch, but even that...") that it'd be hard
to defend (endlessly?).


excatly *that* would be the desired result if configured that way 
because the "clear wire" is controlled and trusted in that context and 
you *want* the secure flag sent for cookies between the tls-offloading 
server and the enduser to not get them back unencrypted over the "real 
clear wire"


the whole purpose of *tls offloading* is run the application on a 
virtual machine with a preforked httpd and encryption on the 
reverse-proxy running multithreaded with keep-alive


another secuity gain here is that the amchine which runs application 
code never has a change to see the private ssl key while a breach on the 
proxy with no application code is less likely



if(!empty($cms_tls_offload))
{
 $_SERVER['REQUEST_SCHEME'] = 'https';
 $_SERVER['HTTPS']  = 'on';
}


Your choice ;)

Re: how make backend applications aware about tls-offloading

[Yann Ylavic]

On Sun, Jan 8, 2017 at 12:22 AM, Reindl Harald  wrote:
>
> ok, so we need to continue the code below and set the option in every
> tls-offloaded application - intention of this thread was maybe get this
> transparent which seems not to be possible

It is "technically" possible, but not wise IMHO.
Making every httpd module/CGI/app think the local connection is https
could lead to things like "; Secure" cookies sent on the (clear) wire,
and that option would be accompanied with so much warnings ("unless
you're really on the same switch, but even that...") that it'd be hard
to defend (endlessly?).

>
> if(!empty($cms_tls_offload))
> {
>  $_SERVER['REQUEST_SCHEME'] = 'https';
>  $_SERVER['HTTPS']  = 'on';
> }

Your choice ;)

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 07.01.2017 um 23:53 schrieb Yann Ylavic:

On Sat, Jan 7, 2017 at 11:25 PM, Reindl Harald  wrote:

Am 07.01.2017 um 22:53 schrieb Yann Ylavic:


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]


That wouldn't work anyway, both variables will be overridden later
when the env is constructed.


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


OK, that's a prerequisite in any case..


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


Admittedly.


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


Right, but HTTPS and REQUEST_SCHEME have a meaning for the httpd
server, and they refer to its *local* configuration, so overriding
them is very misleading (and does not work as mentioned above).

Thus RemoteTLSHeader cannot be something that overrides them, and the
best it could do is to unset the header if not trusted.


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


From the above, the app would have to rely on the (un)defined
RemoteTLSHeader instead of HTTPS/REQUEST_SCHEME, so it can't be as
transparent you'd like...

A new mod_remoteip feature for what you could do with mod_rewrite or
mod_headers is less appealing then


ok, so we need to continue the code below and set the option in every 
tls-offloaded application - intention of this thread was maybe get this 
transparent which seems not to be possible


if(!empty($cms_tls_offload))
{
 $_SERVER['REQUEST_SCHEME'] = 'https';
 $_SERVER['HTTPS']  = 'on';
}

Re: how make backend applications aware about tls-offloading

[Yann Ylavic]

On Sat, Jan 7, 2017 at 11:25 PM, Reindl Harald  wrote:
>
> Am 07.01.2017 um 22:53 schrieb Yann Ylavic:
>>
>> 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]

That wouldn't work anyway, both variables will be overridden later
when the env is constructed.

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

OK, that's a prerequisite in any case..

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

Admittedly.

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

Right, but HTTPS and REQUEST_SCHEME have a meaning for the httpd
server, and they refer to its *local* configuration, so overriding
them is very misleading (and does not work as mentioned above).

Thus RemoteTLSHeader cannot be something that overrides them, and the
best it could do is to unset the header if not trusted.

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

>From the above, the app would have to rely on the (un)defined
RemoteTLSHeader instead of HTTPS/REQUEST_SCHEME, so it can't be as
transparent you'd like...

A new mod_remoteip feature for what you could do with mod_rewrite or
mod_headers is less appealing then.

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 07.01.2017 um 22:53 schrieb Yann Ylavic:

On Sat, Jan 7, 2017 at 9:30 AM, Reindl Harald  wrote:


something like below where "X-TLS-Offloading" is only evaluated from
"RemoteIPInternalProxy" pyhsical addressess

RemoteIPHeader X-Forwarded-For
RemoteTLSHeaderX-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

Re: how make backend applications aware about tls-offloading

[Yann Ylavic]

On Sat, Jan 7, 2017 at 9:30 AM, Reindl Harald  wrote:
>
> something like below where "X-TLS-Offloading" is only evaluated from
> "RemoteIPInternalProxy" pyhsical addressess
>
> RemoteIPHeader X-Forwarded-For
> RemoteTLSHeaderX-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.

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 07.01.2017 um 17:04 schrieb Jered Floyd:

Does the "sslheaders" experimental plugin meet your needs?

https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/sslheaders.en.html


not really beause it's not transparent to the application and so i can 
continue fake the $_SERVER vars based on application configs - it also 
needs to make sure that this headers never ever are passed through from 
untrusted amchines in front fo the own proxy or faked by clients 
pointing directly to the origin - the way mod_remoteip works takes cae 
of such things


"end-to-end" don't matter when both ATS and httpd are on the same switch 
or even running on the same vritualization host - what matters much more 
is that your applications is aware about the https fact and set the 
*encryption flag for cookies* as example


the fake-by-configuration hacking makes things just more complex because 
you have one more place to care besides DNS, ATS and httpd and the 
Magento hacks placing $_SERVER['xyz'] into 'index.php' are anything but 
not beautiful


well, and for sites which should be reachable with https *and* http you 
can forget this entirely when don't have any clue



- On Jan 7, 2017, at 3: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
RemoteTLSHeaderX-TLS-Offloading
RemoteIPInternalProxy  192.168.196.1

Re: how make backend applications aware about tls-offloading

[William A Rowe Jr]

On Sat, Jan 7, 2017 at 2:30 AM, Reindl Harald  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
> RemoteTLSHeaderX-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.

Re: httpd-2.2.x and C89... ;-(

[Yann Ylavic]

On Sat, Jan 7, 2017 at 1:35 AM, William A Rowe Jr  wrote:
> Great catch, thanks Norm. That too is part of the r1753592 backport
> proposal, hoping someone is willing to look at these proposals.

Now backported to 2.2.x (r175), along with other accepted "SNI" patches.
Norm, does it work for you?

On Sat, Jan 7, 2017 at 12:20 PM, Jan Ehrhardt  wrote:
> NormW in gmane.comp.apache.devel (Sat, 7 Jan 2017 11:31:32 +1100):
>> D:\Projects\svn\httpd-2.2.x>svn diff
>> Index: modules/proxy/mod_proxy.c
>> ===
>> --- modules/proxy/mod_proxy.c   (revision 1777591)
>> +++ modules/proxy/mod_proxy.c   (working copy)
>> @@ -1088,9 +1088,9 @@
>>   * backend itself but by the proxy e.g. a bad gateway) in order to 
>> give
>>   * ap_proxy_post_request a chance to act correctly on the status 
>> code.
>>   */
>> +int post_status = proxy_run_post_request(worker, balancer, r, conf);
>>  saved_status = r->status;
>>  r->status = access_status;
>> -int post_status = proxy_run_post_request(worker, balancer, r, conf);
>>  /*
>>   * Only restore r->status if it has not been changed by
>>   * ap_proxy_post_request as we assume that this change was 
>> intentional.
>
> r (or rather r->status) is changed in between the added line and the
> deleted line, so it seems better to do it like this:

Right, though r175 combined another change which avoided the
warning altogether.

Thanks anyway Norm/Jan for testing/review.

Regards,
Yann.

Re: httpd-2.2.x and C89... ;-(

[Jan Ehrhardt]

NormW in gmane.comp.apache.devel (Sat, 7 Jan 2017 11:31:32 +1100):
> D:\Projects\svn\httpd-2.2.x>svn diff
> Index: modules/proxy/mod_proxy.c
> ===
> --- modules/proxy/mod_proxy.c   (revision 1777591)
> +++ modules/proxy/mod_proxy.c   (working copy)
> @@ -1088,9 +1088,9 @@
>   * backend itself but by the proxy e.g. a bad gateway) in order to 
> give
>   * ap_proxy_post_request a chance to act correctly on the status 
> code.
>   */
> +int post_status = proxy_run_post_request(worker, balancer, r, conf);
>  saved_status = r->status;
>  r->status = access_status;
> -int post_status = proxy_run_post_request(worker, balancer, r, conf);
>  /*
>   * Only restore r->status if it has not been changed by
>   * ap_proxy_post_request as we assume that this change was 
> intentional.

r (or rather r->status) is changed in between the added line and the
deleted line, so it seems better to do it like this:

>   * backend itself but by the proxy e.g. a bad gateway) in order to 
> give
>   * ap_proxy_post_request a chance to act correctly on the status 
> code.
>   */
> +int post_status;
>  saved_status = r->status;
>  r->status = access_status;
> -int post_status = proxy_run_post_request(worker, balancer, r, conf);
> +post_status = proxy_run_post_request(worker, balancer, r, conf);
>  /*
>   * Only restore r->status if it has not been changed by
>   * ap_proxy_post_request as we assume that this change was 
> intentional.

-- 
Jan

how make backend applications aware about tls-offloading

[Reindl Harald]

* 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
RemoteTLSHeaderX-TLS-Offloading
RemoteIPInternalProxy  192.168.196.1