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