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 <h.rei...@thelounge.net>:

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

Reply via email to