Re: proxy_fcgi directives or envvars?

[Jim Jagielski]

It would be nice to avoid the overhead of getting
the ENV.

> On Jan 8, 2017, at 11:31 AM, Eric Covener  wrote:
> 
> We have an issue in proxy_fcgi in 2.4.21 and later that makes me think
> we need to tell proxy_fcgi when it's talking to php-fpm vs. a generic
> fastcgi application, due to historical things in httpd and php-fpm.
> Basically, we cleaned up some fcgi variables that php-fpm was
> interpreting as not only Apache-originated but proxy_fcgi vs.
> mod_fastcgi.
> 
> I notice that even complex proxy submodules (proxy_http) have no
> directives but use envvars for config.  I actually like this approach
> for obscure-ish things, but directives do have some benefits (error
> checking, better doc)
> 
> Anyone have strong feelings either way?
> 
> -- 
> Eric Covener
> cove...@gmail.com

Re: proxy_fcgi directives or envvars?

[Nick Kew]

On Sun, 2017-01-08 at 11:31 -0500, Eric Covener wrote:

I'm easy either way.

> I notice that even complex proxy submodules (proxy_http) have no
> directives but use envvars for config.  I actually like this approach
> for obscure-ish things, but directives do have some benefits (error
> checking, better doc)

I think (from distant memory) I may be responsible for some of that.
At some point I wanted to introduce directives where there were none.
But mod_proxy had, by convention, put all the directives in mod_proxy
itself, including some that belonged on the same docs page as what
I needed to add.  I have an idea something may have been needed in
both mod_proxy and mod_proxy_http.  It certainly gave rise to issues
with how to document it without a major reorg.  Envvars offered a
straightforward workaround.

-- 
Nick Kew

proxy_fcgi directives or envvars?

[Eric Covener]

We have an issue in proxy_fcgi in 2.4.21 and later that makes me think
we need to tell proxy_fcgi when it's talking to php-fpm vs. a generic
fastcgi application, due to historical things in httpd and php-fpm.
Basically, we cleaned up some fcgi variables that php-fpm was
interpreting as not only Apache-originated but proxy_fcgi vs.
mod_fastcgi.

I notice that even complex proxy submodules (proxy_http) have no
directives but use envvars for config.  I actually like this approach
for obscure-ish things, but directives do have some benefits (error
checking, better doc)

Anyone have strong feelings either way?

-- 
Eric Covener
cove...@gmail.com

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 08.01.2017 um 11:01 schrieb Stefan Eissing:

There is the reverse situation which is called opportunistic encryption, namely 
the transfer of a http: request over a TLS connection.

Both cases are tricky on HTTP/1.x because the URI scheme is not transported in requests 
(commonly. the spec would allow it but no one does it, so no one is prepared to 
honor/handle it). HTTP/2, with opportunistic encryption in mind, added the 
":scheme" header for this. But implementation is also tricky.

So, mod_http2 has similar problems to this ATS setup: convincing the request 
processing parts in the server that a request has a certain scheme, 
*independent* of mod_ssl's presence. I think it would be nice if we could fix 
this.

One approach that comes to mind:
 * add the uri scheme to request_rec->scheme
 * set it by:
   1. parse the request uri
   2. if not set, fix it in very late read hooks to "http:"
   3. have mod_ssl install an earlier hook that sets "https:" if not present
 * check that URI host and Host: header are an allowed combination
 * check that r->scheme and r->server are an allowed combination

ATS would then be configured to forward requests to the httpd backend by using 
absolute request uris (so they carry the scheme) or HTTP/2. httpd would be 
configured to accept https: uris from ATS remote ip.

And while there are numerous parts/applications where the wheels fall off in 
such a setup, it is not the default setup. No one initially needs to be able to 
get it right. But in a concrete deployment, the configuration can be made and 
the application code fixed where necessary.


yeah - something more or less standard instead
a) change this in tttpd config
b) change this in ATS config, dunno how handle it with a different proxy
c) change this in your application

when there is something you can detect in the application code when 
proxy / backend play in a more or less defined way together other 
proxies and backend servers could follow



Am 07.01.2017 um 09:30 schrieb 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

Re: how make backend applications aware about tls-offloading

[Stefan Eissing]

There is the reverse situation which is called opportunistic encryption, namely 
the transfer of a http: request over a TLS connection.

Both cases are tricky on HTTP/1.x because the URI scheme is not transported in 
requests (commonly. the spec would allow it but no one does it, so no one is 
prepared to honor/handle it). HTTP/2, with opportunistic encryption in mind, 
added the ":scheme" header for this. But implementation is also tricky.

So, mod_http2 has similar problems to this ATS setup: convincing the request 
processing parts in the server that a request has a certain scheme, 
*independent* of mod_ssl's presence. I think it would be nice if we could fix 
this.

One approach that comes to mind:
 * add the uri scheme to request_rec->scheme
 * set it by:
   1. parse the request uri
   2. if not set, fix it in very late read hooks to "http:"
   3. have mod_ssl install an earlier hook that sets "https:" if not present
 * check that URI host and Host: header are an allowed combination
 * check that r->scheme and r->server are an allowed combination

ATS would then be configured to forward requests to the httpd backend by using 
absolute request uris (so they carry the scheme) or HTTP/2. httpd would be 
configured to accept https: uris from ATS remote ip.

And while there are numerous parts/applications where the wheels fall off in 
such a setup, it is not the default setup. No one initially needs to be able to 
get it right. But in a concrete deployment, the configuration can be made and 
the application code fixed where necessary.

Cheers,
Stefan

> Am 07.01.2017 um 09:30 schrieb 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
> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de